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