servlet-spec
  1. servlet-spec
  2. SERVLET_SPEC-24

Clean-up of JNDI resources on application stop

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      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.

        Activity

        Hide
        arjan tijms added a comment -

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

        Show
        arjan tijms added a comment - >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?
        Hide
        markt_asf added a comment -

        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.

        Show
        markt_asf added a comment - 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.
        Hide
        arjan tijms added a comment -

        >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'?

        Show
        arjan tijms added a comment - >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'?
        Hide
        rojkov added a comment -

        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.

        Show
        rojkov added a comment - 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.
        Hide
        markt_asf added a comment -

        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.

        Show
        markt_asf added a comment - 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.
        Hide
        rojkov added a comment -

        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.

        Show
        rojkov added a comment - 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.
        Hide
        Shing Wai Chan added a comment -

        Adding it to the bucket of FUTURE_RELEASE

        Show
        Shing Wai Chan added a comment - Adding it to the bucket of FUTURE_RELEASE

          People

          • Assignee:
            Shing Wai Chan
            Reporter:
            markt_asf
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: