On 6/27/2016 1:03 AM, Mark Eggers wrote:
Jerry,
On 6/26/2016 10:07 PM, Jerry Malcolm wrote:
On 6/26/2016 8:27 PM, David Kerber wrote:
On 6/26/2016 1:32 AM, Jerry Malcolm wrote:
I have a webapp that runs on a single host. It has one primary
database. But it has many secondary databases. There is one
secondary database for each of my clients that use my app. These
client databases come and go regularly as clients signup and
leave. I don't want to have to edit Tomcat conf files adding and
deleting <Resource> tags for the secondary databases and then
have to bounce Tomcat several times a day as clients come onboard
or leave.
I have one <Resource> tag for the primary database. The id/pw
and everything else in the resource tag is the same for all of
the databases. Is there a way to specify/override the url (i.e.
the database name) at runtime to connect to whatever secondary
database I need for the particular client? Or is there a way to
clone a datasource for a different url/database? I still would
like to use the one resource tag in the context.xml.default conf
file to specify the id/pw for the secondary DBs. I'd prefer not
to hardcode id/pw in the java code. But if that is the only
option, I can do it.
Hopefully there is some way to dynamically select the db in a
datasource at runtime... (??) Suggestions?
You can move your authentication code into your application,
rather than having TC handle it. Then you can pick any database or
data source you want.
I know I can hardcode the connection in the code. But that is not
going to provide connection pooling. That 's a huge performance hit.
I really want the same capability I get with jdbc datasources, only
without hardcoding hundreds of them in the conf files.
From what I remember of your environment, it's the following:
1. Monolithic web application
2. No WAR file
3. Much of the configuration is in Tomcat-wide locations
To me (and I don't mean to sound harsh) this violates the software
architecture principle of separating things that change from things that
remain the same (speed of change being relative).
This lack of separation leads to a lot of operational challenges (which
you've written about in the past).
In an ideal world, I'd use versioned WAR files and a CI / CD server (we
use Jenkins) to manage the deployment. Keep context.xml in version
control, and you end up with the potential for a zero down time update.
There are a lot of wrinkles to the above solution that I could go over,
but since this is not your architecture I won't fill up the mailing list
with some likely scenarios.
That being said, I can see three paths for you to go down.
1. Put everything into context.xml
You'll have to edit it and upload the file. When context.xml is changed
Tomcat will reload the web application. You'll experience some downtime,
but with your current architecture I don't see an easy way around that.
2. Roll your own pools
There are several JDBC connection libraries available. You would roll
your own pool management, and then create an administrator application
to add and delete pools.
3. Move to an application server
Wildfly and Glassfish both have administrative interfaces that allow you
to add and delete JNDI JDBC pools. Unfortunatly, the last time I tried
Glassfish the interface to manage JNDI JDBC pools was broken. I don't
know if they've fixed that yet. I've not worked with WildFly, but it
appears to have an administrative interface with this capability.
We're also looking at Elastic Beanstalk, but there are a lot of wrinkles
we need to work out before deciding to move in that direction.
. . . just my two cents
/mde/
I'm not sure what you mean by 'monolithic'. I have 10 virtual hosts
each with about 10 individual webapps. Everything is configured in
individual \conf\Catalina\<host>\context.... and web.xml files.
I am not using WAR files. But only because when I change one jsp or one
jar I don't want to have to wait 15 minutes for an entire WAR refresh
over a slow internet link. But otherwise my architecture is identical
to using WAR files.
None of my configuration is in a Tomcat-wide location.
But I'm not sure what any of this has to do with being able to create a
DataSource using a variable for the database URL. If Wildfly and
Glassfish can do it, it would seem that I would be able to do the same
thing.
I currently use three lines of code to get a DataSource:
Context initContext = new InitialContext();
Context envContext =
(Context)initContext.lookup("java:/comp/env");
DataSource ds = (DataSource)envContext.lookup( "jdbc/myDB" );
I'm assuming that context.lookup(...) simply locates the "jdbc/myDB"
<Resource> tag in the context.xml file, pulls all of the parms out of
that tag, creates a DataSource object utilizing the parms, and returns
it. If that's the case, couldn't I create a variation/subclass of the
Context object that modifies the url parm that it found in the resource
tag and puts the desired db name into the url before constructing the
DataSource?
I have read several places and had several responses that keep
recommending that I write my own datasource. In my understanding, there
is nothing at all wrong with the current DataSource class. To me, this
is not about the DataSource. Rather it is about the parameters (i.e.
url) that are passed to the DataSource constructor. If I can have a
modified Context class that can change the URL parameter on the fly and
construct the identical datasource, then I have precisely what I want.
So this seems like a question about Context.lookup(...), not about the
DataSource class it constructs.
Am I totally off base here? Is it possible to subclass (or replace) the
Context class to do what I need? Could you point me to the actual impl
Context class that is constructing the DataSource currently?
Alternatively, can I simply just hardcode a "ds = new DataSource(.....)"
call and hardcode all of the parms? I'd prefer to not have to hardcode
id/pw, and all of the parms into the code. But if the modified Context
route won't work, I'll do it that way for now if it will work.
Thanks.
Jerry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
