On Tue, May 9, 2017 at 10:44 AM, <[email protected]> wrote:
> The session may holds a DbConnection which is not thread safe. Any operation
> implying the connection will not be thread safe. So I do not think we are
> not that far from having a thread-safe session.
It would seem to me that the best you could do is:
lock (connection)
{
// ... do something ...
}
Or other appropriate, memory barrier, strongest possible lock, monitor, etc.
> Le samedi 6 mai 2017 15:55:15 UTC+2, Fabio Maulo a écrit :
>>
>> Perhaps its time to think : why the ISession is not thread safe ?
>> May be you can discover that the work to do to make it thread-safe is not
>> so hard.
>> Which part of the session-state is not thread safe ?
>> The weakest class, in term of thread safety, is the
>> StatefulPersistenceContext; make it thread safe and you have most of the
>> problem solved ;)
>>
>> Great work team, great work.
>>
>> Abrazos a todos.
>>
>> On Saturday, May 6, 2017 at 5:00:14 AM UTC-3, Boštjan Markežič wrote:
>>>
>>> Here we need to consider one important thing, ISession is not thread safe
>>> so using Task.WhenAll could be very dangerous as the ISession instance is
>>> passed to the event listeners.
>>> In my opinion the version with a for loop is the way to go as we are
>>> mimic the exact behavior as doing it synchronously, the only difference is
>>> that the next event listener may be executed in a different thread because
>>> of ConfigureAwait(false). If the ISession relies on the thread context then
>>> we should remove also the ConfigureAwait(false) call.
>>> IMHO almost nobody is using more than one event listener of the same
>>> type, even if they do, the number will be very small so using the
>>> Task.WhenAll is not necessary here.
>>>
>>> Best Regards,
>>> Boštjan
>>>
>>> Dne sobota, 06. maj 2017 02.28.09 UTC+2 je oseba Alexander Zaytsev
>>> napisala:
>>>>
>>>> Thanks, Boštjan
>>>>
>>>> Funny :) I'm asking in a context of AsyncGenerator. So, it's how the
>>>> listeners are currently invoked (an example based on
>>>> OnPersistEventListener):
>>>>
>>>> private void FirePersistAsync(IDictionary copiedAlready, PersistEvent
>>>> @event)
>>>> {
>>>> using (new SessionIdLoggingContext(SessionId))
>>>> {
>>>> CheckAndUpdateSessionStatus();
>>>> var persistEventListener = listeners.PersistEventListeners;
>>>> for (int i = 0; i < persistEventListener.Length; i++)
>>>> {
>>>> persistEventListener[i].OnPersistAsync(@event,
>>>> copiedAlready);
>>>> }
>>>> }
>>>> }
>>>>
>>>> And this is how the AsyncGenerator converts it to async:
>>>>
>>>> private async Task FirePersistAsync(IDictionary copiedAlready,
>>>> PersistEvent @event)
>>>> {
>>>> using (new SessionIdLoggingContext(SessionId))
>>>> {
>>>> CheckAndUpdateSessionStatus();
>>>> var persistEventListener = listeners.PersistEventListeners;
>>>> for (int i = 0; i < persistEventListener.Length; i++)
>>>> {
>>>> await (persistEventListener[i].OnPersistAsync(@event,
>>>> copiedAlready)).ConfigureAwait(false);
>>>> }
>>>> }
>>>> }
>>>>
>>>> Which is nonoptimal. The code here asynchronously invokes the listeners
>>>> sequentially one by one.
>>>> I would like to invoke them simultaneously instead by Task.WhenAll:
>>>>
>>>> private async Task FirePersistAsync(IDictionary copiedAlready,
>>>> PersistEvent @event)
>>>> {
>>>> using (new SessionIdLoggingContext(SessionId))
>>>> {
>>>> CheckAndUpdateSessionStatus();
>>>>
>>>> var listeners = listeners.PersistEventListeners
>>>> .Select(l => l.OnPersistAsync(@event,
>>>> copiedAlready).ConfigureAwait(false));
>>>>
>>>> await Task.WhenAll(listeners).ConfigureAwait(false);
>>>> }
>>>> }
>>>>
>>>> So, if anyone is expecting some interdependencies or sequential order of
>>>> invocations between the listeners we would not be able to do so.
>>>>
>>>> Best Regards,
>>>> Alexander
>>>>
>>>> On Sat, May 6, 2017 at 12:15 AM, Boštjan Markežič
>>>> <[email protected]> wrote:
>>>>>
>>>>> Hi Alexander,
>>>>>
>>>>> Yes, I am using two IPreUpdate event listeners in a single
>>>>> ISessionFactory. One is updating the entity audit properties and the other
>>>>> is executing the validation for the entity.
>>>>> The order somehow matters in this case as I want the validation event
>>>>> listener to be executed as last after all properties are populated.
>>>>> If you intend to drop support for registering multiple listeners of the
>>>>> same type it won't be a problem for me as I can still create my own
>>>>> mechanism to spread the event across the system if needed.
>>>>> That is just my opinion.
>>>>>
>>>>> Best Regards,
>>>>> Boštjan
>>>>>
>>>>>
>>>>>
>>>>> Dne četrtek, 04. maj 2017 15.38.07 UTC+2 je oseba Alexander Zaytsev
>>>>> napisala:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I want to know if anyone here expects EventListener of the same type
>>>>>> to run in a particular order.
>>>>>>
>>>>>> Does anyone have ever implemented and registered two event listeners
>>>>>> of the same type to the single ISessionFactory?
>>>>>>
>>>>>> Best Regards,
>>>>>> Alexander
>>>>>
>>>>> --
>>>>>
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "nhibernate-development" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nhibernate-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
--
---
You received this message because you are subscribed to the Google Groups
"nhibernate-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
