Kyle wrote:

I may be misunderstanding the question, but it seems to me that this shouldn't really be an issue.

It's more likely that I don't know enought about tomcat to ask an intelligent question!


You have multiple instances of tamcat running. This means you will have multiple server.xml's (meaning multiple "Engine"s in which you can set up your multiple realms and direct each different realm to whichever db you want to direct it to. As server.xml is unique (in std. format config.) to a tomcat instance, you have complete control over which port-instance looks at which db.

Then how do I isolate the instances of tomcat (and their respective server.xml's? Do I need multiple installations of tomcat on my disk?


Again, because you have multiple instances, you will (should) have multiple contexts/context.xml's (dependent upon your tomcat version) in which you can set up your jdbc resources and the various connect criteria for the different db's.

Ok, I didn't know that. Right now, my jdbc connection criteria is hard-coded in the application (I didn't write it; just inherited it). It is set up to look for a specific ODBC DSN. I can easily change the app to look for a configurable DSN, but don't know how to get that config info into the application.


I may be mistaken, but if the app. is written correctly _and_ the different resources in the different contexts are all set up with the same names, you could even then get away with just having the one context root/appbase with the one jdbcURL context-param in web.xml. In this way, the same code would hit and serve up the different data dependent upon which port-instance of tomcat it was hitting.

I'll have to do some more careful reading about my context and server.xml entries.


DISCLAIMER: I haven't tried this and I'm no tomcat expert, but I personally, at my lvl of expertise, am unaware of any reason why this wouldn't work.

Hopefully, someone more knowledgeable will jump in and correct me if I'm way off base.

K.

Thanks for the response!

Dave




David Kerber wrote:

This question is part tomcat and part java; I'm running on a Windows 2000 server.

I have a situation where I am going to need to run multiple instances of tomcat on a single machine, listening on different ports, but running the same application and hitting a different instance of an identical database (same schema, but on a different server). So what I will need to do is be able to tell each instance of the application on its respective instance of tomcat which database to hit. Can I pass a parameter into tomcat from a conf file based on what port that instance of tomcat is listening on, and then get that parameter into my application? If so, how?

Another option is for my application to grab the machine name and port that it is handling, and hit a "common" database to get the information on what copy of the production to use. But again, I need my app to be able to find port information from tomcat, and I don't know how to do that.

It seems like a 3rd option might be to run each instance of tomcat as a service, logged on with different accounts, and use a user DSN instead of a system DSN, with the same DSN name, but different connection info. Is that possible?

If necessary, I could install multiple instances of my app at different context paths, but I still don't know how to tell them to pick up the correct database connection info. I guess I could make a code change in the first page they hit, the logon.jsp, for each instance, but I'd rather not have to do that unless there really is no other way, because that would be easy to screw up when making changes later on...

Any suggestions as to which of the above approaches would be the best, or another one I haven't thought of?

Thanks!
DAve



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to