I am really not sure we should try to go that route. TransactionScopes do
not play well across threads (and need to be created with a special
argument for supporting async/await pattern).
Le mardi 9 mai 2017 20:52:38 UTC+2, Michael Powell a écrit :
>
> On Tue, May 9, 2017 at 10:44 AM, <fredericdelaporte> 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 .
> > 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.
