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.

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