Destroy method not executing when singleton is false

Question

I'm new to spring framework. While executing a program with singleton is true and specifying a destroy method in xml file, the specified destroy method is executed, but when singleton is false it is not executing.

While searching in google, somewhere i came to know that spring cannot manage the complete life-cycle of non-singleton beans. Then how can we destroy that bean and what is the reason for spring not able to manage the complete life-cycle of non-singleton bean.

Thanks in advance.

Answer 1

If a bean is a Spring singleton, then each time you ask for it, Spring is going to give you the same one. Because of this, Spring must always keep a handle on this bean, and it is therefore going to be available to Spring to be destroyed at ApplicationContext shutdown time.

If a bean is not a Spring singleton, then each time you ask for a bean, you get a new instance of it (with the same configuration). Since Spring has no need to hold on to these beans, they don't keep a handle on them, and without a handle on them, how can they call methods to destroy them at ApplicationContext shutdown time? They can't.

Now, you may be asking, why doesn't Spring keep a list of the beans that have been created from a non-singleton scope? Well, one issue would be memory. If this is a long living app, with lots of requests creating many prototype scoped beans, then we could see Spring keeping track of a lot of objects, and that could eat up valuable memory.

There are certainly other potential issues, likely too many to list here, so I will leave it at that.

Answer 2

From the reference documentation, section 5.5.2:

In contrast to the other scopes, Spring does not manage the complete lifecycle of a prototype bean: the container instantiates, configures, and otherwise assembles a prototype object, and hands it to the client, with no further record of that prototype instance. Thus, although initialization lifecycle callback methods are called on all objects regardless of scope, in the case of prototypes, configured destruction lifecycle callbacks are not called. The client code must clean up prototype-scoped objects and release expensive resources that the prototype bean(s) are holding. To get the Spring container to release resources held by prototype-scoped beans, try using a custom bean post-processor, which holds a reference to beans that need to be cleaned up.

In some respects, the Spring container's role in regard to a prototype-scoped bean is a replacement for the Java new operator. All lifecycle management past that point must be handled by the client. (For details on the lifecycle of a bean in the Spring container, see Section 5.6.1, “Lifecycle callbacks”.)

So the reason is that they decided not to handle destruction when using prototypes. Maybe they found out there could be unexpected issues if it were allowed. So I'm sorry to say that you have to deal with the destruction yourself.

Thinking it a bit more, I guess it makes sense. If you call the method many times, you will always receive a new copy of the bean. And the Spring Container would have to keep a reference to each copy if it were to call the dispose method of each one of them when the container shuts down. This would create an unpleasant memory consumption.