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.
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
>>>> <https://github.com/maca88/SharperArchitecture/blob/master/Source/SharperArchitecture.DataAccess/NHEventListeners/AuditEntityEventListener.cs>
>>>>
>>>> is updating the entity audit properties and the other
>>>> <https://github.com/maca88/SharperArchitecture/blob/master/Source/SharperArchitecture.DataAccess/NHEventListeners/ValidatePreInsertUpdateDeleteEventListener.cs>
>>>>
>>>> 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.
