Ok, I just now removed all dependencies from my filters from my controllers. This means none of my filters tries to use a Dao of it's executing controller. Everything gets injected via the kernel. Still I am getting the same errors, which is quite a bummer and leaves me to suspect, that accessing ISession in an IFilter at all creates this bug (which would be _quite_ a drag). I am under the impression that the default implementation of ISessionManager simply does not have a look, whether the caller comes from a different thread or the same that opened the session.
Could anybody of the maintainers of the Nhibernate Integration Facility confirm this? Or at least tell me where to look... 2009/10/23 Jan Limpens <[email protected]> > We found a likely issue, but have not yet implemented it: > > From filters (which are probably assyncronous) we are accessing entities > and daos from the controllers. I imagine this can lead just to our > situations, but this is unconfirmed so far. > > 2009/10/23 Jan Limpens <[email protected]> > > Well so far I have not heard anything from Ayende, unfortunately. >> My setup is kind of similar, I think. >> >> What I tried was to change the lifestyle of my daos - no result. >> disabling AutomaticTransactionManagement did not do anything as well. >> So my guess is on NHibernateIntegration. But I am unsure if testing the >> same with rhino commons unitOfWork will invalidate atm... >> >> 2009/10/19 Artur Dorochowicz <[email protected]> >> >> >>> Francisco, >>> >>> Sorry for such a late reply, it was a busy time recently. >>> >>> I have tried your suggestion and it did not help. I have completely >>> disabled Castle Logging Facility and even removed log4net config file. >>> Still, I get the alert in NHibernate Profiler. >>> >>> I see that Jan involved Ayende in the discussion on this topic on >>> Castle Users Group. I hope he will find us a solution. >>> >>> >>> Artur >>> >>> >>> >>> On 15 Paź, 09:17, "Francisco A. Lozano" <[email protected]> wrote: >>> > Try to completely disable your own log4net logging and see if nhprof >>> > still throws these alarms. >>> > >>> > Francisco A. Lozano >>> > >>> > On Thu, Oct 15, 2009 at 08:33, Artur Dorochowicz >>> > >>> > <[email protected]> wrote: >>> > >>> > > I have exactly the same problem, although my app is still early in >>> > > production and I didn't (yet) see my 'server crash'. >>> > >>> > > I have the same setup: Castle Monorail + Windsor + NHibernate >>> > > Integration Facility, and no manual management of threads. >>> > > Yet, NHProf is alerting about session usage from different threads. >>> > >>> > > To investigate a bit more I have configured log4net to log thread ids >>> > > for NH loggers and indeed I could see that on concurrent requests >>> > > sessions were disposed on different thread than they had been >>> created. >>> > > I'm not sure if this was the only problem and that that was the only >>> > > thing that triggered NHProf alert. >>> > >>> > > I'm also looking forward to seeing this resolved or explained if this >>> > > is not a real issue. >>> > >>> > > Artur >>> > >>> > > On 14 Paź, 22:12, Jan Limpens <[email protected]> wrote: >>> > >> Hi, >>> > >>> > >> NhProf keeps telling me that on _some_ requests of my webb app my >>> > >> session/transactions seem to use multiple threads. >>> > >> And the server sometimes enters into a race condition, where too >>> many >>> > >> requests kill sql server (problems with closing transactions that >>> are >>> > >> already disposed of, sounding just like what you would expect from >>> > >> multiple threads per session). >>> > >>> > >> Now, nowhere i my code I am even coming close to managing my >>> threads. >>> > >> From my point of view 1 thread should be all I need. I am using >>> > >> Monorails with castle windsor integration. My daos are created per >>> web >>> > >> request, sessions come from castle's NHibernateIntegrationFacility >>> and >>> > >> Automatic Transaction Facility, so these might need my love in some >>> > >> way, but I cannot tell from the outside. >>> > >>> > >> Are there some good debug paths to find out what is wrong before I >>> get >>> > >> the next server crash? >>> > >>> > >> ....I might have posted this to the castle list, but I suppose most >>> > >> people who could help me there read this list as well, and nh is at >>> > >> the center of all this... >>> > >>> > >> -- >>> > >> Jan >>> > >>> > >>> >>> >>> >> >> >> -- >> Jan >> > > > > -- > Jan > -- Jan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
