Tomcat 6.0.32 only connects to first deployed application configuration

[chris haskins]

We have an application that connects properly with Tomcat 5.5, but when deployed on tomcat 6.0.32 it will only read one of the applications jdbcutil.properties files. i have tried creating a context.xml in the meta-inf folder catalina/localhost, server.xml, but nothing i do makes a difference. when i deploy more than one application, tomcat only reads the first applicatins dbcp connection information.

We make reference in the web.xml pointing to the path and jdbcutil.properties file which contains the database connection information.
here is a sample piece of web.xml and jdbcutil.properties file.

I'm sure it has to do with the updated servlet 2.5 and jsp 2.1

Any help greatly appreciated



<servlet>
<servlet-name>jdbc.pool.DBConnectionMgr</servlet-name>
<display-name>DBConnectionMgr</display-name>
<description>Connection Pool Servlet</description>
<servlet-class>jdbc.pool.DBConnectionMgr</servlet-class>
<init-param>
<param-name>jdbc.pool.property.file</param-name>
<param-value>D:\Tomcat\webapps\comfiqa896\WEB-INF\config\jdbcutil.properties</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>


# Database Connection Pooling
# Specify the database pool provider - if line is commented out, then original comprizon pool will be used.
# DBCP is the Jakarta DBCP library.
jdbc.pool.provider=DBCP

# Configure the driver to use for connecting to the database
#
# Oracle: pool.driver=oracle.jdbc.driver.OracleDriver
pool.driver=oracle.jdbc.driver.OracleDriver

# Configure the connection string for connecting to the database
#
# Oracle: driver.url=jdbc:oracle:thin:@127.0.01:1521:db_sid
driver.url=jdbc:oracle:thin:@127.0.0.1:1521:sid (connection information removed)
# Configure the username and password for connecting to the database
#
# --- ORGINAL BIZDOC ENCRYPTION ALGORITHM
driver.user=BFhEEA4EP27J2PIB
driver.password=l2GJNo-hoS8BUFGDbS
decrypt.class=jdbc.util.DecryptBizdoc
readonly.user=
readonly.password=

[Tim Holloway]

Welcome to the JavaRanch, Chris!

You appear to be using a servlet to manage a JDBC connection pool. Why are you doing that instead of the more common practice of letting the container (Tomcat) handle the connection pool services?

I'm having a little trouble understanding your problem, partly because you're doing things in a non-standard way, but I get the impression that you're perhaps expecting the same instance of the connection pool servlet to be accessible to more than one webapp. But I'm not sure, since that shouldn't have worked in older versions of Tomcat, either.

If you're instantiating a separate copy of this servlet in each webapp, then I could see they possibility of a resource contention issue. However, above and beyond that, it's not an efficient use of resources. You'd need a separate set of connections for each webapp (and Oracle charges money for extra connections) and the pools would be operating without the ability to balance resource on a global scale. Both of which are reasons why it's preferable to let Tomcat handle the connection pools.

[chris haskins]

Yes, we use an old method of connecting to the data pools this is because the same application can run on SUNOne and OAS. It is being re ritten, for future releases.

Each app is the same as in same software, but different database connections. So configurations change between the databases.
Each application has it's own connection strings like i sampled in the org. post.

What is happening is

tomcat only reads one connection pool form what ever app starts first.

So i have app 1 and app2. I stop and start tomcat, i go to app1 and it is great working fine. i go to app 2, it is up and running as well. but it is looking at app1's database. The connection strings are very different between the app1 and app2. now if i go to the GUI and stop both app1 and app2. i start app2 it starts fine and it is loking at it's proper database. i start app1 and it starts fine and is looking at it's proper database.

If i again stop and start tomcat service, then it will revert to just reading the app1's configuration and not both...

I hope this is clearer in the discription of the issue.

[Tim Holloway]

OK. Integration of connection pools into the J2EE server goes a long, long way back so these apps must be real antiques. I think I was using container-managed pooling in WebLogic in 2000.

There is no way that webapp B should be accessing webapp A's internal resources. They're on different classpaths, for one thing. "Tomcat" isn't running these pools. They're application components, just like all the other servlets and JSPs. They run themselves within the Tomcat container. The distinction is important, because it's yet another reason why you shouldn't be having cross-application contamination.

Of course, one of the things that MIGHT be causing problems is in an area that you haven't illustrated. How does the actual application code get a connection from one of these servlets?

BTW, I recommend always using the forward-slash filename syntax in Java (D:/Tomcat/webapps/comfiqa896/WEB-INF/config/jdbcutil.properties). Backslashes can bite you.

Also, if you're going to keep the config as a resource within the WAR itself, a better way to reference it is by using the getResource J2EE method and using its WAR resource path ("/WEB-INF/config/jdbcutil.properties"). I do hope you're only reading resources from WARs and not attempting to write anything there. That's an entirely different can of worms.

[chris haskins]

i agree, "There is no way that webapp B should be accessing webapp A's internal resources. They're on different classpaths, for one thing. "Tomcat" isn't running these pools. They're application components, just like all the other servlets and JSPs. They run themselves within the Tomcat container. The distinction is important, because it's yet another reason why you shouldn't be having cross-application contamination"

But it in fact does, and no matter how i configure it it still does. The only way to get each app to read is to start the tomcat service, login to the GUI( new for mealways just restarted the service) stop the application that isn't conencting properly and start it again. then it reads its proper configuration.

Im not a developer, just helping in the engineering department.

SO "Of course, one of the things that MIGHT be causing problems is in an area that you haven't illustrated. How does the actual application code get a connection from one of these servlets? "

When the applicationstarts it creates it's connection pools with the sections i sent. In the jdbcutil.properties file we open min 10 max 50 conection pools. the application itself still uses the Invoker

Is this what you meant by " How does the actual application code get a connection from one of these servlets? "

Maybe I'll try deploying from the GUI and see if it has a different affect.


Chris

[Tim Holloway]

When I asked "how does the application code get a connection", I meant literally that.

Obviously this architecture is too old to be using injection, so that implies that when the app needs to access the database, it has to have explicit java code that contacts the servlet class and somehow obtains a connection from the pool.

The standard technique is to use JNDI services to locate the necessary resources, but that can't work here, so I have no way of deducing what mechanisms were used instead except by by seeing a representative sample of an application's JDBC connection-obtaining Java code.