Nonsingleton release

[kuubajz]

Hello,

I have simple question about release of objects (beans lifecycle). I have non singleton bean having reference to singleton(s). Is the "bean lifecycle manager" able to release the non-singleton instance? Do I have to override finalize method when I explicitly finalize the object - i.e. null references to non-singletons?

Thank you for your comments

James

[karldmoore]

If you are dealing with Prototypes, then its up to you to release any resources. If its simply a bean that has a reference to another bean, then standard Java scoping rules apply. If your dealing with the web based scopes, then there is a default callback to release the bean when the relevent event occurs.

There is one quite important thing to be aware of when deploying a bean in the prototype scope, in that the lifecycle of the bean changes slightly. Spring cannot (and hence does not) manage the complete lifecycle of a prototype bean: the container instantiates, configures, decorates and otherwise assembles a prototype object, hands it to the client and then has no further knowledge of that prototype instance. This means that while initialization lifecycle callback methods will be (and are) called on all objects regardless of scope, in the case of prototypes, any configured destruction lifecycle callbacks will not be called. It is the responsibility of the client code to clean up prototype scoped objects and release any expensive resources that the prototype bean(s) are holding onto. (One possible way to get the Spring container to release resources used by singleton-scoped beans is through the use of a bean post processor which would hold a reference to the beans that need to be cleaned up.)

http://static.springframework.org/sp...opes-prototype

[Costin Leau]

Spring is not going to manage non-singleton beans - that is after the bean has been initialized, Spring doesn't track the object anymore. There have been some discussions recently on the forum along with explanations on why is that.
In general, if you have non-singletons which have to release some resources on 'destructions', you have to add your own mechanism such as a manager that can properly close them down.

[karldmoore]

Spring is not going to manage non-singleton beans - that is after the bean has been initialized, Spring doesn't track the object anymore. There have been some discussions recently on the forum along with explanations on why is that.

In general, if you have non-singletons which have to release some resources on 'destructions', you have to add your own mechanism such as a manager that can properly close them down.

OK, I'm confused now. Prototype in unmanaged, but I thought that the web-based scoped were managed by Spring. The standard DisposableBean contract still applies, when the request completes or the session is invalidated. I could be getting my wires crossed but I thought thats what the code seems to say.
http://forum.springframework.org/showthread.php?t=32678

[kuubajz]

Hello, thank you for your answer. I am using older version of Spring 1.2.1 - I have only two options - singleton="false"/"true". But the main idea is that: I must override the finalize method to disable the reference to singletons because the object can not be garbage collected - the non singleton object has reference to objects which are still alive.

[karldmoore]

Hello, thank you for your answer. I am using older version of Spring 1.2.1 - I have only two options - singleton="false"/"true". But the main idea is that: I must override the finalize method to disable the reference to singletons because the object can not be garbage collected - the non singleton object has reference to objects which are still alive.

Surely there isn't a problem here. You need to do cleanup if you have a database connection that needs to be released. If you simply have references to some other beans, your bean can be GC. This is only a problem when someone has a reference to you, hence you can't be GC.

[Costin Leau]

Sorry for the confusion; in this context by non-singleton I meant prototypes and not scoped beans.
Scoped beans have to be managed somehow since otherwise a new instance will be returned in the same scope which is not what you want.

[kuubajz]

Well, I had a problem something like:

<bean id="noSingletonBean" singleton="false">
<property name="refToSingleton">
<ref bean="singletonBean"/>
</property>
</bean>

<bean id="singletonBean" sigleton="true">

and my question was: do I have to care take of bean lifecycle management, e.g. explicit finalization code in nonSingletonBean class when the instance is being finalized?
- nonSingleton and nonSingleton bean do not hold reference to any resource, db, file and they are simple POJO with some logic.

And the solution is:
The nonSingletonBean class does not need to implement any code and all instances can be garbage collected.

Thanks to all!

[karldmoore]

Yep, that sounds right.

[jetmuzer]

And the solution is:
The nonSingletonBean class does not need to implement any code and all instances can be garbage collected.

Oh.. i can't believe, but i found it! Thanks a lot for the solution