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/
signature.asc
Description: OpenPGP digital signature
