{"id":733,"date":"2009-10-15T21:00:32","date_gmt":"2009-10-15T20:00:32","guid":{"rendered":"http:\/\/www.gamlor.info\/wordpress\/?p=733"},"modified":"2021-03-11T09:44:57","modified_gmt":"2021-03-11T08:44:57","slug":"db4o-single-object-container-concurrency","status":"publish","type":"post","link":"https:\/\/www.gamlor.info\/wordpress\/2009\/10\/db4o-single-object-container-concurrency\/","title":{"rendered":"db4o: Single Object-Container Concurrency"},"content":{"rendered":"

Today nearly every application has some concurrent parts. In a classic desktop-application some work is done in the background to keep the application responsive. In a web-application more than one request are handled concurrently. There\u2019s no escape from the challenges of concurrent programs.\u00a0<\/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

Is a Object Container Thread Safe?<\/h3>\n

Short answer: Yes it is. You can throw as many threads as you like at a IObjectContainer. A big fat lock protects all operations on the IObjectContainer. It even goes further. You even can grab that lock yourself, but it’s not recommended!<\/p>\n

\"synchronized<\/a>

synchronized object-container<\/p><\/div>\n

But Your Persistent-Classes Aren\u2019t!<\/h3>\n

So now we know that the object-container is thread safe. Hurray, so lets throw a quazillion threads at it =). Again a little demonstration. Since you cannot \u2018control\u2019 concurrent operations I just simulate some interleaving. Such a simulation never ever shows the real effects of race-conditions, but it\u2019s deterministic to demonstrate the effects.<\/p>\n

One thread takes the Price and Amount and calculate the sum and stores it. The other thread doubles the Amount and cuts the Price in half. So the sum should be always the same, right? The start-values are: Amount = 2, Price = 4.<\/p>\n

So the first interleaving:<\/p>\n

var toUpdate = GetTheUpdateObject();\r\nInOtherThreadThisRanThrought(\r\n    () =>\r\n    {\r\n        var toUpdateT2 = GetTheUpdateObject();\r\n        toUpdateT2.Amount = toUpdate.Amount * 2;\r\n        toUpdateT2.Price = toUpdate.Price \/ 2;\r\n        db.Store(toUpdateT2);\r\n    });\r\nvar sum = toUpdate.Price;\r\nsum = sum * toUpdate.Amount;\r\ntoUpdate.Sum = sum;\r\nConsole.Out.WriteLine(\"Sum is=\"<\/span>+toUpdate.Sum+\" Expected is 8\"<\/span>);\r\ndb.Store(toUpdate);<\/pre>\n
The second interleaving:<\/p>\n
var toUpdate = GetTheUpdateObject();\r\nvar sum = toUpdate.Price;\r\nInOtherThreadThisRanThrought(\r\n    () =>\r\n    {\r\n        var toUpdateT2 = GetTheUpdateObject();\r\n        toUpdateT2.Amount = toUpdate.Amount * 2;\r\n        toUpdateT2.Price = toUpdate.Price \/ 2;\r\n        db.Store(toUpdateT2);\r\n    });\r\nsum = sum * toUpdate.Amount;\r\ntoUpdate.Sum = sum;\r\nConsole.Out.WriteLine(\"Sum is=\"<\/span> + toUpdate.Sum + \" Expected is 8\"<\/span>);\r\ndb.Store(toUpdate);<\/pre>\n
The first interleaving will return the correct result. The second one will return 16, because between the reads of \u2018Price\u2019 and \u2018Amount\u2019 the \u2018Amount\u2019 was changed. (As you remember from previous posts, the object-container caches the objects and returns always the same instances)<\/p>\n
Well the object-container is thread-safe, but actually that doesn\u2019t do much for us.<\/p>\n
\"non-synchronized<\/a>
non-synchronized object manipulation<\/p><\/div>\n
Ok, I Just Synchronize The Persisted Classes<\/h3>\n
Ok, we could synchronize all properties and methods on the persisted classes. But it won\u2019t fix the problem above. Since the race-condition happens between the reads of the two properties.<\/p>\n
Keep It Simple Solution, No Concurrent Operations<\/h3>\n
Well the simplest solution is to avoid any concurrency on the data-operations. So you never ever touch your persistent objects and database concurrently. This actually will work quite good in a simple single-user CRUD-Application.<\/p>\n
However, as soon as your operations on the database and persistent objects takes more time, this isn\u2019t a good solution. (the classic UI-freezes).<\/p>\n
Big Fat Lock Solution<\/h3>\n
This another quite obvious solution. You create a Big-Fat-Lock which protects all operations on the db and persistent objects. So you can ensure that everything stays consistent:<\/p>\n
lock(dbLock)<\/p>\n
load and store persistent objects<\/p>\n
do work with persistent objects<\/p>\n
release(dbLock)<\/p>\n
Yes, it\u2019s still pretty non-concurrent, but it\u2019s enough for lots of applications. It works fine as long the Application is IO-bound anyway and you don\u2019t to computation-intensive stuff.<\/p>\n
This is the way I do it in my application. It allows to run some operations in the background without blocking the rest. Here comes the closure-style API handy:<\/p>\n
dataBase.InTransaction(\r\n    tx=>{\r\n        db.Store(new<\/span> DemoObject());\r\n    });<\/pre>\n
The InTransaction-Method ensures that the the transaction is either committed or rolled back and that the Big-Fat-Lock is hold. Now I do every manipulation on your persistent-object in such a closure.<\/p>\n
Pay attention how you use your persistent-object. For example when you use data-binding (WPF-Binding, Beans-Binding in JAVA). Such binding-mechanisms won\u2019t grab your db-lock. So If you want to just bind the persistent object to the GUI this approach won\u2019t work.<\/p>\n
\"big<\/a>
big fat lock<\/p><\/div>\n
Finer Grained Mechanisms<\/h3>\n
The solution above a pretty simple, but won\u2019t scale a at all. When you really need more performance you need finer grained lock mechanisms. Like per class-lock, per object-lock or whatever strategies fits your usage.<\/p>\n
But What About Client-Server?<\/h3>\n
So far I\u2019ve talked about stuff isn\u2019t that special to db4o and I assumed that there\u2019s only one object-container around. But what about the db4o client-server-model, which has more than one object-container? I haven\u2019t lost a word about it. So that is the topic of the upcoming blog-post =)<\/p>\n
100th Post<\/h3>\n
Just noticed that this is the 100th post on my blog. Yuppie =)<\/p>\n
\"100th<\/a>
100th post<\/p><\/div>\n
Demo-Files: InterleavingDemo.cs<\/a>, SimpleObject.cs<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
Today nearly every application has some concurrent parts. In a classic desktop-application some work is done in the background to keep the application responsive. In a web-application more than one… <\/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\/733"}],"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=733"}],"version-history":[{"count":7,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/posts\/733\/revisions"}],"predecessor-version":[{"id":3830,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/posts\/733\/revisions\/3830"}],"wp:attachment":[{"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/media?parent=733"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/categories?post=733"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/tags?post=733"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}