Thanks, Nevin. I certainly appreciate your deep treatment of my question/issue!
I would like to ask for clarification about a point in your #2:
> (2) CONTAINER-MANAGED CONNECTION POOL.
> (a) using container injection
>
> @Resource(name="....")
> private DataSource datasource
>
> (b) traditional JNDI lookup
>
> Context naming = new InitialContext();
> DataSource datasource = (DataSource) naming.lookup("....");
With either 2a or 2b, for a given JNDI resource name, regardless of where in my
JAX-RS Java code I get the DataSource, I can be certain that I am getting a
DataSource/connection from a container-managed connection pool, and so there is
no need to cache anything within my application, right?
The only stumbling block for me is that in our application, databases are added
at runtime, and I don't believe there is a way to add a JNDI Resource
definition at runtime (i.e., <GlobalNamingResources> or <Context> element of
particular application). Since databases are not added rapid-fire, I suppose
each time one is added I could dynamically generate a new server configuration
file under a temporary name, adding Resources for all databases, then run a
script that shuts down Tomcat, replaces the server configuration copy with the
newly generated one, and restart Tomcat. A little clumsy, I suppose, but the
benefit would be significant.
> (3) APPLICATION-MANAGED CONNECTION POOL.
Alternatively, I can manage my own cache of connection pools (i.e.,
org.apache.tomcat.jdbc.pool.DataSource instances), keyed off of database name
in a HashMap, for example, and storing that cache in an object that is
persisted across web service calls (using JAX-RS Features). Do you see any
problem with retaining org.apache.tomcat.jdbc.pool.DataSource instances in
memory and re-using them for extended periods of time?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
