I have a J2EE webapp which is used to upload a file which is then processed by a database procedure. Because we do not want the webapp to have to wait until the database procedure completes, it is executed in a different thread.
The process running in the separate thread needs to obtain and close its own connection. The webapps usually look up the datasource jndi name using a ServiceLocator which in turn looks it up from the application context (the lookup key for the jndi name is defined as a class constant) but for the separate thread looking up the jndi name with the ServiceLocator fails. To get around this problem we have used the jndi name as the class constant instead, so that the thread can look up the datasource directly.
This means that the jndi name for the datasource is now fixed for the application, and we can no longer deploy the same application in the same container but with different datasources simply by modifying the web.xml.
What are industry best practices around this? Should the jndi name be configurable or is it OK to fix it for the application? Has anyone implemented a configurable datasource jndi name solution that is usable both in the webapp and by other threads in the container?
Best Answer
Yeah - I feel your pain.
I do think it is a very good idea to try and make the jndi configurable via the web.xml. The way I've handled this is cached the datasource reference. iow, on startup of the webapp the datasource referenced is sourced while it is available to the thread and then passed to or made available to any other object which requires it.