Does DataObjects real world applications use multithreading?

Can you show me samples?

What about implementation of PLinq for DataObjects?

Previously, you got from me a test case with an error in parallel (on different threads) reading an object in one (the same)session.

Do you have this test case?

asked Jan 26 '12 at 10:02

Ibanez's gravatar image

Ibanez
15669

edited Jan 26 '12 at 16:06


3 Answers:

Dataobjects.Net handles very well multi threading in our application.

However there is two requirements:

  • Never share session between threads
  • Choose correctly your default transaction isolation level to avoid locking and deadlocks (we use snapshot transaction isolation level)

Disclaimer : I'm a DO.Net user, not developper.

answered Jan 26 '12 at 10:44

olorin's gravatar image

olorin
358858792

1

I agree with olorin. Not following these two requirements is the most common source of multithreading issues with DataObjects.Net

(Jan 26 '12 at 11:35) Denis Krjuchkov Denis%20Krjuchkov's gravatar image

Yeah, you can easily shoot yourself in the foot violating the above-mentioned requirements.

In short, Session was intentionally designed for use in single-threaded environment.

As for the test, I will check its presence.

(Jan 26 '12 at 11:41) Dmitri Maximov Dmitri%20Maximov's gravatar image

But you must ensure any of these threads doesn't use the same Session object (or any of objects it provides) simultaneously with another one.

Of course I can synchronize access to objects by means of .net synchronization capabilities, for example, Lock () {} statement or using such collections as ConcurrentBag, ConccurrentDictionary. But it is very difficult to do because it'll affect code of other programmers, and even Core code.

I don't understand Why can't DO provide thread safe read access to Session-like objects.

In fact, basically, this problem occurs when accessing the so-called hardcoded properties.

For example:

public static class HardcodedRoles
{
    /// <summary>Руководитель депозитария</summary>
    public static Role DepositaryLead
    {
        get { return Session.Current.Query.Single<Role>(Guid.Parse("24b384f0-a60d-4ecf-8381-a06d30facbe9")); }
    }        
}

I can not provide synchronized access to these properties due to the reason described above.

answered Jan 26 '12 at 14:42

Ibanez's gravatar image

Ibanez
15669

edited Jan 27 '12 at 11:12

Never share session between threads. Session was intentionally designed for use in single-threaded environment.

This is sad. Then tell me what to do with the following situation. There is an action that already has an opened transaction (I do not control the opening of the outer transaction). Within this action, I create a set of persistent objects, and i want to run multiple threads, each of which will use these objects as shared resources.

If a new thread to open a new session, then when you access a collection of objects arises 'Session Switch Exception'. If you try to query these objects from the database, they are simply not persist in it, because the transaction in which they were created is not yet complete (I do not control the completion of this transaction)

Of course if the task can be divided into independent subtasks without shared resources, then no problem paralleling

answered Jan 26 '12 at 13:20

Ibanez's gravatar image

Ibanez
15669

Actually, the answer isn't fully correct:

  • You can share session between multiple threads
  • But you must ensure any of these threads doesn't use the same Session object (or any of objects it provides) simultaneously with another one.

And I confirm this is fully intended design. Caches in DO are pretty complex, moreover, there is lazy loading, so even when you just read the data concurrently using the same Session, racing is possible. And if you'll face such a case, it will be really hard to debug it.

(Jan 26 '12 at 14:09) Alex Yakunin Alex%20Yakunin's gravatar image

AFAIK, such a requirement for Session-like objects is valid for any other ORM. I.e. you can pass such an object to another thread, but can't use it concurrently.

(Jan 26 '12 at 14:10) Alex Yakunin Alex%20Yakunin's gravatar image

Don't use the objects as shared resource. Share their keys (entity.Key), and open a session in each thread, instantiate the entity with sesssion.Query.Single<t>(key).

(Jan 27 '12 at 03:06) olorin olorin's gravatar image

In my case it does not help because session.Query.Single<t>(key) returns nothing. As i described Above.

(Jan 27 '12 at 04:10) Ibanez Ibanez's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

Subscription:

Once you sign in you will be able to subscribe for any updates here

Tags:

×2

Asked: Jan 26 '12 at 10:02

Seen: 2,425 times

Last updated: Jan 27 '12 at 11:12

powered by OSQA