3

I know questions about .net ORM have been asked thousands of times, but i want to know which ORM is easy to work with in a multithreaded environment. Commercial or Free are both welcomed.

Currently, I am using XPO from Devexpress, but i feel it awkward to use in a multithread app. The object from one thread can't be shared by another thread, to use it in another thread i have to find the object from DB using the key, it's really annoying. You can't persist the DB object's state to DB, even if you lock the state of the object. e.g. the Save() method can't be called from another thread other than the one create the object.

BTW, i am just getting started with XPO, maybe I am using it wrong.

cspolton
  • 4,495
  • 4
  • 26
  • 34
Benny
  • 8,547
  • 9
  • 60
  • 93
  • 1
    Whenever you start sharing objects across threads you will have problems. You need to implement your own locking, regardless of ORM support. – Oded Dec 04 '10 at 14:02
  • Every O/RM can be used in a multi-threaded environment. So please explain what you are trying to do. What kind of multi-threaded environment are use using and in which way. – Steven Dec 04 '10 at 14:20

3 Answers3

1

nHibernate has been used in many applications, some of which are multi-threaded.

See the documentation on concurrency, specifically section 10.2 - it clearly says that ISession is not thread safe (so you need to manage this yourself).

Can you please clarify what would make an ORM "easy to work", as far as you are concerned?

Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • Even with locking, the object is not shareable in XPO, you just can't call save() from another thread. – Benny Dec 04 '10 at 14:19
1

Every O/RM works perfectly in a multi-threaded application. I've used LINQ to SQL and Entity Framework in ASP.NET applications (which are multi-threaded per definition).

If you're having trouble using your O/RM in a multi-threaded environment, you are probably using it wrong. For instance, most O/RM tools have a type that implements the Unit of Work pattern (such as LINQ to SQL's DataContext, Entity Framework's ObjectContext, and XPO's Session). A unit of work is meant to be created by and controlled by a single thread. If you use such an object this way, I have never had any trouble using an O/RM tool in a multi-threaded environment.

Steven
  • 166,672
  • 24
  • 332
  • 435
  • 1
    It is sweeping to say that *every* O/RM works perfectly in a multi-threaded application. – cspolton Dec 04 '10 at 13:52
  • @Spolto: Name one that doesn't. – Steven Dec 04 '10 at 13:54
  • Entity Framework 4. If you use a object context long enough in a separate thread, the data could easily become stale. – Robin Orheden Dec 04 '10 at 13:57
  • NHibernate as quoted by Oded. You are correct that they generally designed to be used in a single threaded way. – cspolton Dec 04 '10 at 14:03
  • 1
    None of the O/RM frameworks have a unit of work that is thread-safe, but that doesn't mean the framework itself can't be used in multi-threaded applications. – Steven Dec 04 '10 at 14:16
0

The ObjectContext in Entity Framework is neither thread-safe, so you'll probably have to implement your own with locking to it if you want to have it as a shared resource.

You could create a new object context for every thread, but if you have a lot of threads spawning/dying, this could easily become a performance issue.

Also, having a ObjectContext for each thread could result in data staleness. As stated below:

Last but not least is of course the issue of multi-user concurrency. An ObjectContext caches its entities forever and ever until it is disposed. If another user changes the same entities on his own ObjectContext, the owner of the first ObjectContext will never find out about that change. These stale data problems can be infuriatingly difficult to debug, because you can actually watch the query go to the database and come back with fresh data, but the ObjectContext will overwrite it with the old, stale data that's already in the cache. This, in my opinion, is probably the most significant reason to avoid long-lived ObjectContext instances; even when you think you've coded it to grab the most recent data from the database, the ObjectContext will decide that it's smarter than you and hand you back the old entities instead.

Entity Framework Object Context in ASP.NET Session object?

Community
  • 1
  • 1
Robin Orheden
  • 2,714
  • 23
  • 24