Lifecycle with reference counting

[Robert Turner]

Hi fellow Windsorers,

I've got an application where a particular component implementation is provided externally (by an Activator), but I only want it to be destroyed when the instance has been released the same number of times that it was resolved. I'm wondering if there is a particular lifestyle that implements reference counting such that the activator is called for the first resolve, and then for subsequent resolves the same instance is returned, then when the component is completely released (release called the same number of times as resolve) the instance is destroyed. I tried registering it with a transient lifestyle and always returning the same instance, but of course upon subsequent resolves I get an error that the particular instance is already being tracked.

Firstly: Given that the requirement for destroying the component once there are no remaining references to it is valid, does a resolve/release reference counting lifestyle sound like the right approach, or is the an alternative?

Secondly: Are there any reference implementations for the preferred approach? If not then creating a lifestyle similar to transient but with reference counting isn't too difficult.

Cheers,

Rob

[hammett]

So it's a "singleton" that you want to destroy only after everybody is done with it, correct?

Since Resolve<> should only be called at the root level (infrastructure code) - unless you're doing the no-no pattern of exposing a container globally - you should have some cue on when you app is ending, and thus kill the foreign component. 

Regarding the other question, I dont think we tried anything like that previously. From the old COM days, ref counting has been taken as a hard approach to get right and may lead to many issues. 

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-u...@googlegroups.com.
To post to this group, send email to castle-pro...@googlegroups.com.
Visit this group at http://groups.google.com/group/castle-project-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Cheers,
hammett
http://www.d-collab.com/
http://hammett.castleproject.org/

[Robert Turner]

The use case is for a factory interface with both create and release methods, where the instance is a proxy for RPC over a communication channel. After all resolved instances are released I want to free the communication resources, which in this case is a messaging saga.

Yeah I definitely agree about the issues of ref counting re the old COM days. I'll try minimise the issues with a sealed implementation.

Cheers for the input.

Rob

On Friday, 3 May 2013 03:13:05 UTC+2, hammett wrote:

So it's a "singleton" that you want to destroy only after everybody is done with it, correct?

Since Resolve<> should only be called at the root level (infrastructure code) - unless you're doing the no-no pattern of exposing a container globally - you should have some cue on when you app is ending, and thus kill the foreign component. 

Regarding the other question, I dont think we tried anything like that previously. From the old COM days, ref counting has been taken as a hard approach to get right and may lead to many issues. 

On Fri, Apr 26, 2013 at 4:01 AM, Robert Turner <rob...@gmail.com> wrote:

Hi fellow Windsorers,

I've got an application where a particular component implementation is provided externally (by an Activator), but I only want it to be destroyed when the instance has been released the same number of times that it was resolved. I'm wondering if there is a particular lifestyle that implements reference counting such that the activator is called for the first resolve, and then for subsequent resolves the same instance is returned, then when the component is completely released (release called the same number of times as resolve) the instance is destroyed. I tried registering it with a transient lifestyle and always returning the same instance, but of course upon subsequent resolves I get an error that the particular instance is already being tracked.

Firstly: Given that the requirement for destroying the component once there are no remaining references to it is valid, does a resolve/release reference counting lifestyle sound like the right approach, or is the an alternative?

Secondly: Are there any reference implementations for the preferred approach? If not then creating a lifestyle similar to transient but with reference counting isn't too difficult.

Cheers,

Rob

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-users+unsub...@googlegroups.com.

To post to this group, send email to castle-pro...@googlegroups.com.
Visit this group at http://groups.google.com/group/castle-project-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.