{"id":779,"date":"2009-11-06T17:09:35","date_gmt":"2009-11-06T16:09:35","guid":{"rendered":"http:\/\/www.gamlor.info\/wordpress\/?p=779"},"modified":"2021-03-11T09:44:57","modified_gmt":"2021-03-11T08:44:57","slug":"db4o-client-server-and-concurrency","status":"publish","type":"post","link":"https:\/\/www.gamlor.info\/wordpress\/2009\/11\/db4o-client-server-and-concurrency\/","title":{"rendered":"db4o: Client-Server and Concurrency"},"content":{"rendered":"

So far we\u2019ve always used a single object container. This it the simplest way to used db4o. Just open an embedded database an use it. In this post I\u2019ll give a short introduction to the client-server-features of db4o. Handling concurrency is more challenging in a server-client scenario, therefore I also loose a few words about that.<\/p>\n

(All posts of this series: the basics<\/a>, activation<\/a>, object-identity<\/a>, transactions<\/a>, persistent classes<\/a>, single container concurrency<\/a>, Queries in Java, C# 2.0<\/a>, client-server concurrency<\/a>, transparent persistence<\/a>, adhoc query tools<\/a>)<\/p>\n

Embedded Client-Server<\/h3>\n

Let\u2019s assume we build a small web application. Naturally multiple requests are handled concurrently. Of course you want to run each request independent from other request. Having a transaction for each request would be nice, because then you can rollback the transaction when a request fails. So far we\u2019ve always used a single object-container. Additionally we know that a transaction is bound to a object-container. In order to support our scenario we need more than one object container. No problem, it quite easy:<\/p>\n

const<\/span> int<\/span> RunEmbeddedServer = 0;\r\nvar server = Db4oClientServer.OpenServer(FilePath, RunEmbeddedServer);\r\nvar db1 = server.OpenClient();\r\nDoStuffWith(db1);\r\nvar db2 = server.OpenClient();\r\nDoStuffWith(db2);<\/pre>\n
<\/pre>\n
Creating a new server is really easy. You pass in the database-file, a optional configuration and a port-number to the factory and you\u2019re done. When you pass a 0 as port-number an embedded server<\/a> is created. You can open as many clients as you want on this embedded server with the .OpenClient()-method.<\/p>\n
For our small web application this is wonderful solution. We still have an embedded database without additional deployments, administration and so forth. The server just runs within the web application.<\/p>\n
\"db4o-cs\"<\/a><\/p>\n
Client-Server Over a Network<\/h3>\n
Before we created an embedded client-server. But what if the clients are to be different processes on different devices? Well the step is really small, you take the calls above and specify additionally the port and grant access to users. Now your server is ready to accept clients over the network<\/a>:<\/p>\n
The server:<\/p>\n
const<\/span> int<\/span> RunAsRealServer = 8080;\r\nvar server = Db4oClientServer.OpenServer(FilePath, RunAsRealServer);\r\nserver.GrantAccess(\"db4o\"<\/span>,\"passwordOfUser\"<\/span>);<\/pre>\n
The client:<\/p>\n
using<\/span>(var db = Db4oClientServer.OpenClient(\"localhost\"<\/span>, 0, \"db4o\"<\/span>, \"passwordOfUser\"<\/span>))\r\n{\r\n    DoStuffWith(db);\r\n}<\/pre>\n
<\/pre>\n
Opening a server and connecting clients of the network isn\u2019t much more work. The .OpenClient()-method on the server still works. So the server-process can open internal clients, for example to execute maintenance-work. Of course opening a connection over the network has way more overhead than opening embedded clients.<\/p>\n
\"db4o-cs-network\"<\/a><\/p>\n
Server With \/ Without Classes<\/h3>\n
Now running the server and clients in different process brings a whole new complexity with it. Remember that the classes actually is the schema of your database? I also said that a query might cannot be optimized and the actual objects are instantiated to run the queries. That\u2019s why there\u2019s a big difference to have a server which has all persisted classes and a server which only runs a pure db4o instance. A server without persisted classes cannot execute all kinds of queries<\/a>. Here I think it shows that db4o\u2019s focuses on embedded scenarios.<\/p>\n
\"db4o<\/a>
db4o without or with persistet classes<\/p><\/div>\n
Isolation Between Clients<\/h3>\n
First lets check something very simple. In the post about object-identity<\/a> I said that object-container keeps references to the loaded objects. It\u2019s used to keep track of identity and for caching purposes. So how does this work in client-server-mode when multiple object-containers are around? To check this we load the same object from different object-containers. Then we check if the objects are the same by identity:<\/p>\n
var client1 = server.OpenClient();\r\nvar client2 = server.OpenClient();\r\nvar objFromClient1 = (from SimpleObject o in<\/span> client1\r\n                         where<\/span> o.Name == \"first-Obj\"<\/span>\r\n                         select o).Single();\r\nvar objFromClient2 = (from SimpleObject o in<\/span> client2\r\n                         where<\/span> o.Name == \"first-Obj\"<\/span>\r\n                         select o).Single();\r\nAssertTrue(ReferenceEquals(objFromClient1, objFromClient2),\"Have a shared reference-cache\"<\/span>);<\/pre>\n
<\/pre>\n
The assert will fail! Because each client object-container has its own reference-tracking. Basically a client object-container acts the same as a simple object-container. When you have multiple object-containers in your application, it\u2019s extremely important that objects are always loaded and stored with the same object-container instance. Otherwise you run into the magic-clone issue I\u2019ve described in the object-identity-post<\/a>.<\/p>\n
Now to the next big question. When is a change from one object-container visible to the other object-container? As already mentioned in the transaction-post<\/a>, db4o has read-committed isolation properties<\/a>. Here\u2019s a little example to illustrate this. We open two client object-containers. The first client stores some object in the database. When the second client queries the database it doesn\u2019t see the stored objects, until the first client commits its changes:<\/p>\n
var client1 = server.OpenClient();\r\nvar client2 = server.OpenClient();\r\n\r\nclient1.Store(new<\/span> SimpleObject(\"first-Obj\"<\/span>,2,2));\r\nclient1.Store(new<\/span> SimpleObject(\"first-Obj\"<\/span>,3,3));\r\n\r\nvar countBeforeCommit = (from SimpleObject o in<\/span> client2\r\n                         select o).Count();\r\nAssertTrue(0 == countBeforeCommit,\"Doesn't see stuff from first client\"<\/span>);\r\n\r\nclient1.Commit();\r\n\r\nvar countAfterCommit = (from SimpleObject o in<\/span> client2\r\n                        select o).Count();\r\nAssertTrue(2 == countAfterCommit,\"After commit it does see the stuff from the first client\"<\/span>);<\/pre>\n
\"db4o-isolation\"<\/a><\/p>\n
Beware Of Cached Instances<\/h3>\n
Ok, the object-containers are well isolated and changes are visible after commits. Ready for more? Let\u2019s take a look at the example code below. Again we open two client object-containers. Each get’s the object by its name. Then the first client changes the name, stores and commits the changes. After that we get the object by its new name on the second client object-container. Then we compare the names. Will it run fine?<\/p>\n
var client1 = server.OpenClient();\r\nvar client2 = server.OpenClient();\r\nvar objFromClient1 = LoadObjectByName(client1, \"old-name\"<\/span>);\r\nvar objFromClient2 = LoadObjectByName(client2, \"old-name\"<\/span>);\r\nAssertTrue(objFromClient1.Name==objFromClient2.Name,\"Names are equal\"<\/span>);\r\n\r\nobjFromClient1.Name = \"new-name\"<\/span>;\r\nclient1.Store(objFromClient1);\r\nclient1.Commit();\r\n\r\nobjFromClient2 = LoadObjectByName(client2, \"new-name\"<\/span>);\r\nAssertTrue(\"new-name\"<\/span> == objFromClient2.Name, \"Names are equal\"<\/span>);<\/pre>\n
Well the result is probably unexpected. The second assertion fails. What the fuck? We ran the query with the \u2018new-name\u2019 and retrieved the object. But the object actually has the \u2018old-name\u2019? That\u2019s totally inconsistent! Well here the reference-cache plays a dirty trick. As said, db4o holds references to already loaded object and only returns the instantiated object to avoid unnecessary de-serialization. Because the second client object-container already has a instance of the object it simple returns the existing instance. Unfortunatetly the object in memory doesn\u2019t have the same state as the object in the database. This is a very common issue with all database-systems. You can explicitly refresh an object. This will read set a object in memory to the state in the database:<\/p>\n
const<\/span> int<\/span> activationDeph = 4;\r\nclient2.Ext().Refresh(objFromClient2, activationDeph);<\/pre>\n
Or you open for each task a new client object-container. In the embedded client-server mode this is quite a good solution, since its cheap to open a new client. Over a network its rather a costly operation.<\/p>\n
However in the end you\u2019ve always a race condition, because another client could do something between the refresh and the store-operation.<\/p>\n
\"cached<\/a>
cached objects<\/p><\/div>\n
Locking<\/h3>\n
As seen above db4o hasn\u2019t a very \u2018strict\u2019 concurrency model. Therefore you might need more control. For this purpose db4o provides low-level locks<\/a>. The API is simple:<\/p>\n
const<\/span> int<\/span> timeOutInMilliSec = 1000;\r\ntry<\/span>\r\n{\r\n    objContainer.Ext().SetSemaphore(\"name_of_semaphore\"<\/span>, timeOutInMilliSec);\r\n    DoWork();\r\n\r\n}finally<\/span>\r\n{\r\n    objContainer.Ext().ReleaseSemaphore(\"name_of_semaphore\"<\/span>);\r\n}<\/pre>\n
<\/pre>\n
Often the name of the semaphore is derived from the object-id to ensure that the name is unique. A small example. Again we open two client object-containers. The first one grabs a lock. Then we check on another thread if we can get the lock there.<\/p>\n
const<\/span> int<\/span> timeOut = 100;\r\nvar client1 = server.OpenClient();\r\nvar client2 = server.OpenClient();\r\nif<\/span> (!client1.Ext().SetSemaphore(\"lock-demo\"<\/span>, timeOut))\r\n{\r\n    throw<\/span> new<\/span> InvalidOperationException(\"Expect that I can get lock\"<\/span>);\r\n}\r\nvar couldGetLockOnClient1 = false<\/span>;\r\nvar couldGetLockOnClient2 = false<\/span>;\r\nvar thread = new<\/span> Thread(()=>\r\n   {\r\n       couldGetLockOnClient1 = client1.Ext().SetSemaphore(\"lock-demo\"<\/span>, timeOut);\r\n       couldGetLockOnClient2 = client2.Ext().SetSemaphore(\"lock-demo\"<\/span>, timeOut);\r\n   });\r\nthread.Start();\r\nthread.Join();\r\nAssertTrue(couldGetLockOnClient1, \"client1 can get lock. Also in other threads\"<\/span>);\r\nAssertTrue(!couldGetLockOnClient2, \"client2 cannot get lock, since it's hold by client1\"<\/span>);<\/pre>\n
<\/pre>\n
Here\u2019s one important thing to notice. The Thread we run can acquire the lock from the first client, but not from the second. So db4o locks work on a object-container. They have nothing to do with thread-synchronization like the lock-statement.<\/p>\n
Normally you build some kind of wrappers around this low-level-mechanism. For example to have this convenient way to lock objects.<\/p>\n
dataBase.WithLock(yourAccount, myAccount)\r\n    .Execute(() =>\r\n                 {\r\n                     var transferAmount = 100;\r\n                     yourAccount.Money -= transferAmount;\r\n                     myAccount.Money += transferAmount;\r\n                 });<\/pre>\n
This higher level locking-method is also responsible for ordering the locks, to avoid dead-locks. I\u2019ve added a simple implementation to this blog-entry. No guaranties that is correct though.<\/p>\n
\"db4o-locking\"<\/a><\/p>\n
More Concurrency Stuff<\/h3>\n
Well I think that I\u2019ve covered the very basic concurrency controls in db4o. There are some more building-blocks. For example you can send messages around<\/a>. So you could notify clients about changes via the database-server. Furthermore db4o can keep version-numbers of object around. Maybe useful for for some kind of optimistic locking<\/a>.<\/p>\n
\"concurrency<\/a>
concurrency mad<\/p><\/div>\n
Next Time<\/h3>\n
Well I think I\u2019ve now covered the very basics of db4o. For more information read the documentation<\/a>, or ask it in the forums<\/a>. I will certainly write about db4o sometime in the future =). But next time I\u2019ll take a brief look at another database-technology.<\/p>\n
Files:\u00a0DB4O-ClientServer.cs<\/a>, SimpleObject.cs<\/a><\/p>\n
Lock-Utility: LockExtensions.cs<\/a>, TestLockExtensions.cs<\/a> (Unit-Test require NUnit <\/a>and Moq<\/a>)<\/p>\n","protected":false},"excerpt":{"rendered":"
So far we\u2019ve always used a single object container. This it the simplest way to used db4o. Just open an embedded database an use it. In this post I\u2019ll give… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_links_to":"","_links_to_target":""},"categories":[150],"tags":[21,100],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/posts\/779"}],"collection":[{"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/comments?post=779"}],"version-history":[{"count":8,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/posts\/779\/revisions"}],"predecessor-version":[{"id":3826,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/posts\/779\/revisions\/3826"}],"wp:attachment":[{"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/media?parent=779"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/categories?post=779"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/tags?post=779"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}