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
-~----------~----~----~----~------~----~------~--~---
