Simone this should be fixed with the latest commit.
On Oct 24, 5:00 pm, "Simone Busoli" <[EMAIL PROTECTED]> wrote:
> Ok, now I get it, thanks.
>
> On Fri, Oct 24, 2008 at 10:42 PM, Ayende Rahien <[EMAIL PROTECTED]> wrote:
> > The comment is misleading and should be removed.
> > This is actually an issue with the container failing to start (usually
> > because of configuration error)
>
> > On Fri, Oct 24, 2008 at 10:38 PM, Simone Busoli <[EMAIL PROTECTED]>wrote:
>
> >> I looked into the code to see if UoWApplication would need changes, but I
> >> guess no, since the container is disposed on application end, and therefore
> >> all the components as well. Instead I noticed that the code in
> >> Application_End does this:
>
> >> if (Container != null) //can happen if this isn't the first app
> >> {
> >> IoC.Reset(Container);
> >> Container.Dispose();
> >> }
>
> >> In which case can the container be null? I'm not sure I understand the
> >> comment.. As far as I can see from the property getter it should never be
> >> null. Am I missing something?
>
> >> On Fri, Oct 24, 2008 at 9:54 PM, Brian Rumschlag <[EMAIL PROTECTED]>wrote:
>
> >>> I uploaded another patch with the UnitTests.
> >>> It's NHibernate.Dispose.UnitTests.patch
>
> >>> On Oct 24, 3:47 pm, Jason Meckley <[EMAIL PROTECTED]> wrote:
> >>> > applied, thanks.
>
> >>> > On Oct 24, 3:26 pm, Brian Rumschlag <[EMAIL PROTECTED]> wrote:
>
> >>> > > Patch submitted..
> >>> > > NHibernate.Dispose.patch
>
> >>> > > On Oct 24, 3:16 pm, Brian Rumschlag <[EMAIL PROTECTED]> wrote:
>
> >>> > > > But in that case, the rogue thread keeps right on running.
>
> >>> > > > I have a test case put together across threads instead of
> >>> AppDomains.
> >>> > > > It is behaving as I would expect, the maintenance thread keeps
> >>> running
> >>> > > > and the SF.Dispose() is never called.
> >>> > > > I'll have a patch shortly.
>
> >>> > > > On Oct 24, 3:11 pm, "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
>
> >>> > > > > Shutdown the process, so yes
>
> >>> > > > > On Fri, Oct 24, 2008 at 8:56 PM, Brian Rumschlag <
> >>> [EMAIL PROTECTED]>wrote:
>
> >>> > > > > > Does closing a WinForm shutdown it's AppDomain?
>
> >>> > > > > > On Oct 24, 2:50 pm, "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
> >>> > > > > > > Shutting an appdomain would kill all threads that execute
> >>> code in that
> >>> > > > > > app
> >>> > > > > > > domain
>
> >>> > > > > > > On Fri, Oct 24, 2008 at 8:33 PM, Brian Rumschlag <
> >>> [EMAIL PROTECTED]
> >>> > > > > > >wrote:
>
> >>> > > > > > > > The patch was simple, but the Unit Test is giving me fits.
>
> >>> > > > > > > > I have a Mock CacheProvider working, that when it starts it
> >>> spits off
> >>> > > > > > > > a thread waiting for some signal to stop.
>
> >>> > > > > > > > The Test then fires off another AppDomain to initialize the
> >>> IoC
> >>> > > > > > > > Container, and start the Unit of Work.
>
> >>> > > > > > > > Unfortunately, when that call comes back, and the new
> >>> AppDomain is
> >>> > > > > > > > unloaded, the thread which should keep right on going,
> >>> stops.
> >>> > > > > > > > Also, the static variables I have to check the status of
> >>> the
> >>> > > > > > > > CacheProvider aren't the same inside of the new AppDomain.
>
> >>> > > > > > > > I'm confused.
>
> >>> > > > > > > > On Oct 24, 11:19 am, Jason Meckley <[EMAIL PROTECTED]>
> >>> wrote:
> >>> > > > > > > > > should be as simple as updating 3 files:
>
> >>> > > > > > > > > IUnitOfWorkFactory to
> >>> > > > > > > > > public interface IUnitOfWorkFactory : IDisposable
>
> >>> > > > > > > > > then implement the members here:
> >>> > > > > > > > > ActiveRecordUnitOfWorkFactory (empty member)
> >>> > > > > > > > > NHibernateUnitOfWorkFactory (call sessFactory.Dispose())
>
> >>> > > > > > > > > build, create patch, submit, done:)
>
> >>> > > > > > > > > On Oct 24, 10:43 am, "Ayende Rahien" <[EMAIL PROTECTED]>
> >>> wrote:
>
> >>> > > > > > > > > > Please sumbit a patch with this
>
> >>> > > > > > > > > > On Fri, Oct 24, 2008 at 4:42 PM, Brian Rumschlag <
> >>> > > > > > [EMAIL PROTECTED]
> >>> > > > > > > > >wrote:
>
> >>> > > > > > > > > > > The problem is that the maintenance thread in the
> >>> memcache client
> >>> > > > > > is
> >>> > > > > > > > > > > preventing an implicit Dispose() of the SF
> >>> > > > > > > > > > > I added an explicit dispose method to
> >>> IUnitOfWorkFactory, called
> >>> > > > > > it
> >>> > > > > > > > at
> >>> > > > > > > > > > > the end of application, and everything shut down
> >>> properly.
> >>> > > > > > > > > > > I'll try making the interface implement IDisposable
> >>> instead.
>
> >>> > > > > > > > > > > On Oct 24, 10:16 am, "Ayende Rahien" <
> >>> [EMAIL PROTECTED]> wrote:
> >>> > > > > > > > > > > > I don't think we call SF.Close();
> >>> > > > > > > > > > > > We just the the app domain shut down clean up all
> >>> our
> >>> > > > > > resources.
>
> >>> > > > > > > > > > > > On Fri, Oct 24, 2008 at 3:47 PM, Jason Meckley <
> >>> > > > > > > > [EMAIL PROTECTED]
> >>> > > > > > > > > > > >wrote:
>
> >>> > > > > > > > > > > > > SessionFactory.Dispose() isn't called explicitly.
> >>> not from
> >>> > > > > > what I
> >>> > > > > > > > can
> >>> > > > > > > > > > > > > see. I would assume this is done in
> >>> > > > > > NHibernateUnitOfWorkFactory
> >>> > > > > > > > which
> >>> > > > > > > > > > > > > holds the instance of the factory. but
> >>> IUnitOfWorkFactory
> >>> > > > > > does
> >>> > > > > > > > not
> >>> > > > > > > > > > > > > implement IDisposable.
>
> >>> > > > > > > > > > > > > when the application ends the object is gone (for
> >>> lack of a
> >>> > > > > > > > better
> >>> > > > > > > > > > > > > term). I would assume that when IoC.Rest() is
> >>> called this
> >>> > > > > > > > disposes
> >>> > > > > > > > > > > > > the windsor container, which in tern disposes
> >>> components,
> >>> > > > > > etc.
> >>> > > > > > > > if
> >>> > > > > > > > > > > > > that's the case then we may be able to update
> >>> > > > > > IUnitOfWorkFactory
> >>> > > > > > > > to
> >>> > > > > > > > > > > > > inherit IDisposable. then set
> >>> sessionFactory.Dispose() int
> >>> > > > > > the
> >>> > > > > > > > > > > > > concrete member.
>
> >>> > > > > > > > > > > > > Thoughts?
>
> >>> > > > > > > > > > > > > On Oct 24, 9:17 am, Brian Rumschlag <
> >>> [EMAIL PROTECTED]>
> >>> > > > > > wrote:
> >>> > > > > > > > > > > > > > I have an application that is using memcached
> >>> as it's
> >>> > > > > > > > second-level
> >>> > > > > > > > > > > > > > cache.
>
> >>> > > > > > > > > > > > > > The MemCached library has a maintenance thread
> >>> that runs
> >>> > > > > > until
> >>> > > > > > > > the
> >>> > > > > > > > > > > > > > caching system is destroyed by
> >>> CacheProvider.Stop(), which
> >>> > > > > > is
> >>> > > > > > > > called
> >>> > > > > > > > > > > > > > by SessionFactory.Close.
>
> >>> > > > > > > > > > > > > > SessionFactory.Close is called by
> >>> SessionFactory.Dispose(),
> >>> > > > > > but
> >>> > > > > > > > that
> >>> > > > > > > > > > > > > > doesn't seem to be getting called either.
>
> >>> > > > > > > > > > > > > > Obviously, you wouldn't want to close the
> >>> SessionFactory
> >>> > > > > > when
> >>> > > > > > > > the
> >>> > > > > > > > > > > > > > UnitOfWork was disposed, but I can't find where
> >>> in
> >>> > > > > > > > > > > > > > Rhino.Commons.NHibernate SessionFactory.Close
> >>> is called.
>
> >>> > > > > > > > > > > > > > Any thoughts?
> >>> > > > > > > > > > > > > > Brian Rumschlag
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Rhino Tools Dev" 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/rhino-tools-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
