[SERVLET_SPEC-24] Clean-up of JNDI resources on application stop Created: 07/Oct/11  Updated: 06/Dec/16

Status: Open
Project: servlet-spec
Component/s: Container
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE

 Description   

To facilitate a graceful shutdown of resources that does not rely on GC (which may not happen for some time) it would be helpful if there was a way to signal to JNDI resources that they were no longer required.

The suggestion is that on application stop, the resource is checked for a zero argument close() method and that this method is called if it is present.



 Comments   
Comment by arjan tijms [ 01/Dec/11 ]

>the resource is checked for a zero argument close() method and that this method is called if it is present.

What about checking for the java.lang.AutoCloseable interface instead?

Comment by markt_asf [ 02/Dec/11 ]

That would work if the minimum Java version is Java 7. The proposal was written based on a current Tomcat feature that runs on earlier Java versions.

The disadvantage of using java.lang.AutoCloseable is that it requires that the resource being closed is written for Java 7. That is not always the case. A fall-back for non-Java 7 resources would be nice.

Comment by arjan tijms [ 03/Dec/11 ]

>That would work if the minimum Java version is Java 7

Indeed, but a newer version of the Servlet spec could at least support newer Java versions, couldn't it?

>A fall-back for non-Java 7 resources would be nice.

Sure, although I would be wary of just calling unknown methods that happen to match a given signature. With the java.lang.AutoCloseable we can be sure the resource creator has written the resource being aware that the close() method will be automatically called.

At the very least I think there should be an option to disable the fall-back. It would be strange if a close method didn't just did what it said, but you never known. It's perhaps a bit far-fetched, but what if the JNDI resource represents some administrative system and close() means a domain specific action is carried out, like closing a 'payment period'?

Comment by rojkov [ 07/Dec/11 ]

I am obviously missing something, but how do we know a given resource belongs to the app in question and the app should be closing it.

Comment by markt_asf [ 07/Dec/11 ]

Definition of JNDI resources is container specific but the container will know if the resource is specific to an application or shared and can call / not call the close method accordingly.

Comment by rojkov [ 07/Dec/11 ]

If /foo binds a resource to JNDI for use by /bar, should shutting down /foo close the resource?

I think assumption that a container close any resource with a close() method may go too far, so there should at least be a way to exclude and include resources. And that needs to be weighted against advising programmers to use application specific ContextListener to clean up JNDI tree on shutdown.

Comment by Shing Wai Chan [ 22/Feb/13 ]

Adding it to the bucket of FUTURE_RELEASE

Generated at Fri Jan 20 03:45:36 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.