Hey Maximillian, Well i'm not spawning a new thread intentionally for Log4Net, it just seems to be the way it works. That or I'm mistaking it's behavior and when and if it is called it completes its routine before allowing the calling thread to continue, regardless as to what is happening during the the initial thread/session - we could be half way through a transaction for instance, essentially either way this is the issue with using the same Session.
As for thread-static, I was under the impression that using that statement is generally frowned upon with ASP.NET. I could and probably am wrong but is the only reason why I haven't used that yet. I will try and test ThreadStaticSessionContext to see if that works. Anyway, thanks for all your replies. I appreciate you helping me and have learned quite a bit from your help so thank you. Anthony On Apr 28, 10:39 am, Maximilian Raditya <[email protected]> wrote: > No problem here. > > IC. So this all is about multi-threaded usage of ISessionManager in web > application. I have no experience with multi-threaded ASP.NET so I'm not > sure how I can help you in this area. BTW, I'm curious how do you manage to > create another thread for log4net: by creating new Thread instance? Also > your design rationale that leads you to have log4net run of differet thread > than the HTTP request thread? > > It seems then ISessionManager.OpenSession() is designed to be > single-threaded, means only one ISession created per HTTP request. Perhaps > it should have thread-static ISession context in web application context as > well. I think you can provide a patch if you want to. > Also with NH ISession design (limitation), a single ISession can't be used > by more than one thread. It's single-threaded as well. > > Put aside the limitation of NH Facility, in NH there is a > ThreadStaticSessionContext. Perhaps you can configure NH > CurrentSessionContext (through NH Facility or standalone configuration) to > use that session context, and then see the difference in results. You can > then access the ISession by calling ISessionFactory.GetCurrentSession(). > > -- > Regards, > > Maximilian Haru Raditya > > On Wed, Apr 27, 2011 at 10:05 PM, Anthony Phillips <[email protected]>wrote: > > > > > > > > > Thanks for getting back to me, > > > You've confirmed what I thought. Though for clarity I will explain the > > last issue, thread-safe, a little more clearly. > > > Ok so within a single request, let's say a page: start_request to > > end_request, you would expect only one ISession to be created using > > HttpContext and assuming this is how the NHibernate ISessionManager/ > > Facility works. So this we know and is standard behavior, even in a > > normal NHIbernate setup without Castle. The thing is we can't, and > > shouldn't, just assume only one thread will be used by calling this > > one request. > > > For instance: Log4Net, through my testing, spawns on another thread or > > at least breaks context. So lets say you are in the middle of a > > transaction in the main, initial, thread and for whatever reason > > Log4Net is used during that transaction - which in my case I use > > NHibernate to log to the database, if we call Open/GetCurrentSession > > either with Castle or standalone NHibernate we will then corrupt the > > initial thread's session. > > > So the only solution I could think of was to create a completely new > > ISession on the Log4net thread and either: > > > (A) do this each time it is called, since ISession(s) are meant to be > > light weight, and as a result create as many sessions as there is > > debug/error messages etc > > OR > > (B) create a new ISession and store it under the current context using > > a key/value pair to reference and separate it, the issue here is that > > although it let's us use the same ISession throughout the lifetime of > > the initial thread NHibernate profiler complains that there is too > > many connections/interactions with the database over that single > > session. > > > So I am not sure what to do. Either use one of those options based on > > what people say or maybe you or someone else has a better, simpler > > option to solve the multiple thread issue. > > > Log4Net is just one example, I reckon SessionState would be another > > and I can only assume there are tons more references that will have > > the same issue. > > > I don't know, is there anyway to associate a ISession with not only > > the current context but the thread as well? That way calling > > GetSession will only look for a session on the same thread. Maybe this > > wouldn't work? Maybe we can't assume the single thread will complete > > the single request? > > > I hope maybe that clears it up a little and why I was initially > > thinking ISessionManager would solve this for me. > > > Thanks again for your time, > > > Anthony > > > On Apr 27, 12:25 pm, Maximilian Raditya <[email protected]> wrote: > > > Hello Anthony, > > > > Ah, sorry. It's just I don't clearly understand your issue statement as > > it's > > > a bit confusing. > > > > Let me paraphrase it to make it clearer: > > > > 1. You're using ISessionManager in web application context (by setting > > > isWeb=true). > > > 2. You're assuming and expecting ISessionManager.OpenSession() to > > create > > > a new single ISession (session) when in fact, based on your > > observation, it > > > didn't it. Instead, it just returns already opened session if such is > > > present. You don't expect such behavior and want to open a new session > > > everytime you call OpenSession(), instead of returning existing active > > > (present) session. > > > 3. Based on #2, you want to access ISessionFactory directly since it > > > would give the behavior you expect. > > > > As for #3, yes, you can access ISessionFactory instead of using > > > ISessionManager. In the doc here: > >http://www.castleproject.org/container/facilities/trunk/nhibernate/in..., > > > you can see there are two integration levels (ways) of using NH Facility. > > > First by using ISessionFactory, and second by using ISessionManager. You > > > can use both in web application depends on your need. > > > > As for #2, I think it's the expected behavior since the opened session > > bound > > > to a single HttpContext request (HttpContext.Current), it would span as > > long > > > as it's in a single HttpContext request life time. > > > > Still, I'm not sure what you meant by thread safe. > > > > Hope this helps. > > > > -- > > > Regards, > > > > Maximilian Haru Raditya > > > > On Wed, Apr 27, 2011 at 4:52 PM, Anthony Phillips <[email protected] > > >wrote: > > > > > Hello Maximilian, > > > > > Sorry, I don't mean to frown on any work, I believe the integration is > > > > brilliant. I just figured that when calling OpenSession on the > > > > ISessionManager, since the resulting call is either Open or > > > > GetCurrent, I would of assumed that the ISessionManager would be > > > > thread aware/thread safe since on subsequent calls, on the container, > > > > it forces it to look for the last ambient session, which could be on > > > > another thread. If we were given the option to Open a new ISession, > > > > with ISessionManager, regardless of existing ISession(s) then I would > > > > of not made that assumption. > > > > > Since we can't directly open a new ISession if one is present using > > > > ISessionManager, do correct me if I am wrong, is the suggestion made > > > > to me on StackOverflow a sound one? Can I reference the SessionFactory > > > > from the container using IoC in much the same way I used it in my > > > > example? I guess that would then solve my issue. > > > > > Unless of course, there is a better practice way of using the > > > > ISessionManager thread-safe? If there is, are there any examples > > > > anywhere? I have yet to find any and have spent a day looking. > > > > > Thanks for your time, > > > > > Anthony > > > > > On Apr 26, 10:36 pm, Maximilian Raditya <[email protected]> wrote: > > > > > Hello, > > > > > > I don't honestly understand how you are expecting it to be > > thread-safe. > > > > Mind > > > > > elaborating about it more? I mean what you expect from it to behave, > > and > > > > how > > > > > it doesn't meet your expectation. > > > > > > AFAIK, NHibernate ISession is also NOT thread-safe, but > > ISessionFactory > > > > IS > > > > > thread-safe, as a comparison. > > > > > > -- > > > > > Regards, > > > > > > Maximilian Haru Raditya > > > > > > On Wed, Apr 27, 2011 at 1:37 AM, Anthony Phillips < > > [email protected] > > > > >wrote: > > > > > > > Hello there, > > > > > > > I'm hoping someone can help me and explain the way to do things > > > > > > properly. > > > > > > > I posted my question here: > > >http://stackoverflow.com/questions/5782696/thread-safe-issue-with-cas. > > > > .. > > > > > > > I see no point in retyping it out but if you have a look at that > > and > > > > > > then keep this in mind. How can I use ISessionManager with other > > > > > > threads? > > > > > > > Thanks, > > > > > > > Anthony > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > > > "Castle Project Users" 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/castle-project-users?hl=en. > > > > > -- > > > > > You received this message because you are subscribed to the Google > > Groups > > > > "Castle Project Users" 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/castle-project-users?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Castle Project Users" 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/castle-project-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Users" 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/castle-project-users?hl=en.
