Tomcat, Apache and mod_jk configuration
Hi there, Here is my problem. I got a working Tomcat 5.5.20 handling 4 webapps in /var/tomcat/webapps. I got a working Apache 2, configured with several virtualhosts. I managed to connect the Apache to the Tomcat using an AJP13 connector, and everything is working fine. Now, I'd like to map each one of my webapps to a different virtualhost. For instance, I'd like that my webapp example1, which is in /var/tomcat/webapps/example1, should be accessible through www.example1.com (and NOT www.example1.com/example1 - I've already that working). How do you achieve this using the jkMount directives? I've tried with jkMount /example1/* ajp13 and my webapp is accessible only through www.example1.com/example1. Thanks in advance for your answers! Guillaume de Vinzelles DSI/PFS Neuf Cegetel Altran Technologies [EMAIL PROTECTED] 01 70 18 21 64 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat, Apache and mod_jk configuration
In fact, I've already put the jkMount directive in the VirtualHost conf. It looks like: VirtualHost 88.191.24.6:80 DocumentRoot /var/www/preprod.skyce.net/htdocs Directory /var/www/preprod.skyce.net/htdocs Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all /Directory ServerName preprod.skyce.net ErrorLog /var/www/preprod.skyce.net/log/error_log CustomLog /var/www/preprod.skyce.net/log/access_log common jkMount /struts-dev-1/*.do ajp13 jkMount /struts-dev-1/*.jsp ajp13 /VirtualHost And I'd like to have my webapp accessible through http://preprod.skyce.net/ instead of http://preprod.skyce.net/struts-dev-1/. The pertinent fragment of my server.xml is: Host name=preprod.skyce.net appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false My webapps are located in /var/tomcat/webapps, and I got: CATALINA_BASE: /var/tomcat and CATALINA_HOME: /opt/tomcat5 Thanks ! Guillaume de Vinzelles DSI/PFS Neuf Cegetel Altran Technologies [EMAIL PROTECTED] 01 70 18 21 64 -Message d'origine- De : Michael Courcy [mailto:[EMAIL PROTECTED] Envoyé : jeudi 19 octobre 2006 14:51 À : Tomcat Users List Objet : Re: Tomcat, Apache and mod_jk configuration Hello Here is a fragment of my server.xml Host name=www.verlina.com appBase= unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Aliasverlina.com/Alias Aliastique-et-puce.fr/Alias Aliaswww.tique-et-puce.fr/Alias Aliasshampooing-chien.fr/Alias Aliaswww.shampooing-chien.fr/Alias Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=verlina.com_access_log. suffix=.txt pattern=common resolveHosts=false/ Valve className=org.apache.catalina.valves.FastCommonAccessLogValve directory=logs prefix=verlina.com_access_log. suffix=.txt pattern=common resolveHosts=false/ Context path= docBase=/home/verlina/www/ debug=0 Resource name=jdbc/verlina auth=Container type=javax.sql.DataSource maxActive=100 maxIdle=30 maxWait=1 removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true username=*** password= driverClassName=com.mysql.jdbc.Driver url=jdbc:mysql://localhost:3306/verlina_com?autoReconnect=true/ /Context /Host And here is a fragment of my httpd.conf VirtualHost 87.98.218.193 ServerName www.verlina.com ServerAlias verlina.com ServerAlias tique-et-puce.fr ServerAlias www.tique-et-puce.fr ServerAlias shampooing-chien.fr ServerAlias www.shampooing-chien.fr JkMount /* ajp13 ServerAdmin [EMAIL PROTECTED] #DocumentRoot /home/verlina/www User verlina Group users CustomLog logs/verlina-access_log combined ScriptAlias /cgi-bin/ /home/verlina/cgi-bin/ /VirtualHost The idea is to put the JkMount inside the virtualHost of Apache. But discussing with Mr Caldarale, this layout is weak, even if it works. Because if you make any change to the context, you're forced to restart tomcat instead of just redeploying your context. There should be a way for your app to programatticly communicate to tomcat the list of domain the app should handle, but I don't know how to do that. Cheers. DE VINZELLES, Guillaume (ext.) a écrit : Hi there, Here is my problem. I got a working Tomcat 5.5.20 handling 4 webapps in /var/tomcat/webapps. I got a working Apache 2, configured with several virtualhosts. I managed to connect the Apache to the Tomcat using an AJP13 connector, and everything is working fine. Now, I'd like to map each one of my webapps to a different virtualhost. For instance, I'd like that my webapp example1, which is in /var/tomcat/webapps/example1, should be accessible through www.example1.com (and NOT www.example1.com/example1 - I've already that working). How do you achieve this using the jkMount directives? I've tried with jkMount /example1/* ajp13 and my webapp is accessible only through www.example1.com/example1. Thanks in advance for your answers! Guillaume de Vinzelles DSI/PFS Neuf Cegetel Altran Technologies [EMAIL PROTECTED] 01 70 18 21 64 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users
RE: Tomcat, Apache and mod_jk configuration
Michael and Chris, thanks a lot for your valuable help. I'm going to try this ASAP. The multi instance Tomcat seems really interesting. Thanks again! Regards Guillaume de Vinzelles DSI/PFS Neuf Cegetel Altran Technologies [EMAIL PROTECTED] 01 70 18 21 64 -Message d'origine- De : Christopher Schultz [mailto:[EMAIL PROTECTED] Envoyé : jeudi 19 octobre 2006 15:39 À : Tomcat Users List Objet : Re: Tomcat, Apache and mod_jk configuration Guillaume, In fact, I've already put the jkMount directive in the VirtualHost conf. [snip] And I'd like to have my webapp accessible through http://preprod.skyce.net/ instead of http://preprod.skyce.net/struts-dev-1/. It looks like what to have more than one webapp as the root webapp. My suggestion would be to run each webapp in a different instance of Tomcat. It's much easier than you think is it to do this. I use Tomcat 4.1.x, but I'm sure the same is possible with very few changes on 5.5.x: 1. Create a directory structure for each webapp (outside of Tomcat's installation directory) like this: struts-dev-1/ struts-dev-1/conf struts-dev-1/conf/server.xml struts-dev-1/conf/web.xml struts-dev-1/webapps struts-dev-1/logs struts-dev-1/temp ** Make sure to set your port numbers for your shutdown and connector ports to something unique among your webapps. I usually use 8x85 for the ajp13 connector port and 8x86 for the shutdown port. 2. Install your webapp to the directory struts-dev-1/webapps/struts-dev-1 3. Configure Tomcat to use struts-dev-1 as your root webapp (usually by specifying that the path is instead of /struts-dev-1). 4. Start each Tomcat instance like this: $ export JAVA_HOME=... $ export CATALINA_HOME=/path/to/full/tomcat/install $ export CATALINA_BASE=/path/to/struts-dev-1 $ export CATALINA_TMPDIR=/path/th/struts-dev-1/temp $ /path/to/full/tomcat/install/bin/startup.sh This setup allows you to have separate root webapps (or any other kind of setup). You also have the benefit (I choose to see it as a benefit) of separate JVMs and Tomcat instances. You can take one down without bothering the others. Hope that helps, -chris - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error occurred during initialization of VM
Hi there, I'm a bit surprised of what you get from your java -version. It says gij (GNU libgcj) and as far as I know, gcj is the GNU native java compiler. I can also see that there is a mismatch between the VM version that should be installed (1.5.0_08) and the version returned by java -version (1.4.2). You should follow the previous advices and reinstall the Sun JVM. Regards, Guillaume de Vinzelles DSI/PFS Neuf Cegetel Altran Technologies [EMAIL PROTECTED] 01 70 18 21 64 -Message d'origine- De : Jim Douglas [mailto:[EMAIL PROTECTED] Envoyé : mardi 17 octobre 2006 23:18 À : users@tomcat.apache.org Objet : Error occurred during initialization of VM Everything was ok last week, I just restarted Tomcat today and got this errror message, Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object Tomcat 5.5.14 Apache 2.2 Fedore Core 5 jdk1.5.0_08 (No VM) java -version, from the command line returns, java version 1.4.2 gij (GNU libgcj) version 4.1.1 20060525 (Red Hat 4.1.1-1) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. It seems Tomcat can't find the JVM it could previously, what could this be from? Jim - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Database connection pooling errors in Tomcat 5.5.17
Yes, it does support DBCP. (see my older post about DBCP pool exhaustion). Regards. Guillaume de Vinzelles DSI/PFS Neuf Cegetel Altran Technologies [EMAIL PROTECTED] 01 70 18 21 64 -Message d'origine- De : Saurabh Nanda [mailto:[EMAIL PROTECTED] Envoyé : mardi 17 octobre 2006 14:13 À : Tomcat Users List Objet : Re: Database connection pooling errors in Tomcat 5.5.17 ojdbc14.jar should be in $TOMCAT_HOME/common/lib to be available to both the container and your webapp. Nopes: o Put it in $CATALINA_HOME/common/lib alone -- same error o put it in webapps/appname/WEB-INf/lib and $CATALINE_HOME/common/lib, both -- same error! Does oracle drier support DBCP? Nandz. -- http://nandz.blogspot.com http://foodieforlife.blogspot.com - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Database connection pooling errors in Tomcat 5.5.17
Here is a valid url : url=jdbc:oracle:thin:@address:port:schema Guillaume de Vinzelles DSI/PFS Neuf Cegetel Altran Technologies [EMAIL PROTECTED] 01 70 18 21 64 -Message d'origine- De : David Smith [mailto:[EMAIL PROTECTED] Envoyé : mardi 17 octobre 2006 17:16 À : Tomcat Users List Objet : Re: Database connection pooling errors in Tomcat 5.5.17 Some fishing through source and online -- your problem can happen if the connection url is not recognized by the driver. I was looking at the jdbc url you first posted: jdbc:oracle:thin:[EMAIL PROTECTED] This doesn't come up as a valid form in any online docs I can find. You might want to verify it's valid. --David Saurabh Nanda wrote: ojdbc14.jar should be in $TOMCAT_HOME/common/lib to be available to both the container and your webapp. Nopes: o Put it in $CATALINA_HOME/common/lib alone -- same error o put it in webapps/appname/WEB-INf/lib and $CATALINE_HOME/common/lib, both -- same error! Does oracle drier support DBCP? Nandz. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JDBC Pool exhaustion
Hello, One of our connections wasn't properly closed, as you said. You fixed the problem and now everything is running fine. Thanks to all the people who answered for your help! Guillaume de Vinzelles DSI/PFS Neuf Cegetel Altran Technologies [EMAIL PROTECTED] 01 70 18 21 64 -Message d'origine- De : Richard DeGrande [mailto:[EMAIL PROTECTED] Envoyé : mercredi 11 octobre 2006 17:58 À : Tomcat Users List Objet : Re: JDBC Pool exhaustion Martin, Isn't dbcp connection pooling ?? I think I am missing something, I am not clear on why you are advocating a separate pooling mechanism. Can you elaborate on this a little ? thanks rick Martin Gainty [EMAIL PROTECTED] 10/11/2006 9:15 AM If you have 1000 connections then you would be well advised to use connection pooling more specifically you need to separate the activities of settingup a connection from getting the connection you also need to separate the activities of freeing the connection from connection teardown connection setup and teardown are expensive operations and should be used judiciously continous connection setup and teardown will not only bog down the app but slow the DB as it furiously tries to keep up with these resource requests A vert good primer for setting up connection pools is available at http://www.webdevelopersjournal.com/columns/connection_pool.html A word on SEH for non oo single threaded environments you may swallow the exception if you have deemed the execution of the statement as optional If the statement is required then I would always raise a meaningful exception and not swallow it If you have a OO env such as Java you should raise the exception and handle it by the outermost handler in a structured way (definition of SEH) as an aside I usually pass error_code and description Feel free to Contact me offline for particulars of how to implement, M- - Original Message - From: Christopher Schultz [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, October 11, 2006 10:54 AM Subject: Re: JDBC Pool exhaustion - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JDBC Pool exhaustion
We've checked it two weeks ago, but we got to be sure, so we are doing it again today (and tomorrow, I expect). Thanks for the advice. Guillaume de Vinzelles DSI/PFS Neuf Cegetel Altran Technologies [EMAIL PROTECTED] 01 70 18 21 64 -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Pascal Alberty Envoyé : mercredi 11 octobre 2006 16:10 À : Tomcat Users List Objet : Re: JDBC Pool exhaustion Check your code to unclosed connections (and statments) first ! On 10/11/06, DE VINZELLES, Guillaume (ext.) [EMAIL PROTECTED] wrote: Hello there, We are running a Tomcat 5.5.17 on a Sun Solaris system (SunFire V240) with a Sun JVM 1.5, and we are facing unavoidable JDBC pool exhaustions. We are using an Oracle 9i database. Here is the JDBC entry from our server.xml: Resource name=jdbc/Signup auth=Container type=javax.sql.DataSource driverClassName=oracle.jdbc.driver.OracleDriver url=jdbc:oracle:thin:@address:port:schema username=user password=pass maxActive=120 maxIdle=10 maxWait=5000 removeAbandoned=true removeAbandonedTimeout=60 / The Tomcat manager shows around 1000 sessions on the server, which seems to be pertinent. We can see with the JMXProxy that the JDBC pool connections are never recycled, e.g. the active connections number is going higher and higher and never stays at the same level, which is strange because the amount of active sessions isn't growing. Do you have any idea about what we can do to 'force' the Tomcat server to release the unused JDBC connections? Thanks in advance, Best Regards, Guillaume de Vinzelles DSI/PFS Neuf Cegetel Altran Technologies [EMAIL PROTECTED] 01 70 18 21 64 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pascal Alberty http://pascal.albertyorban.be - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JDBC Pool exhaustion
For Christopher and Alberty, here is an example of how we connect to the
database. I'm quite sure we are using the JDBC pool.
My next step is to try to log the Connection objects life, and I hope to find
some memory leaks!
I got to say that we were using the same application with a Tomcat 4 and a JVM
1.4.08 without any problem.
Thanks for your previous answers!
DataSource ds;
String datasource = jdbc/Signup;
try {
Context ic = new InitialContext();
Context envCtx = (Context) ic.lookup(java:/comp/env);
ds = (DataSource) envCtx.lookup(datasource);
}
catch (NamingException ne) {
logger.error(Error looking up datasource jdbc/Signup : +
e.getMessage());
}
Connection myConnection = null;
CallableStatement oCmd = null;
ResultSet result = null;
try {
myConnection = ds.getConnection();
oCmd = myConnection.prepareCall({call STOREDPROC(?, ?)});
oCmd.registerOutParameter(1, OracleTypes.CURSOR);
oCmd.setString(2, critere);
oCmd.execute();
result = (ResultSet)oCmd.getObject(1);
/* SNIP */
}
catch (Exception e) {
logger.error(e.getMessage(), e);
throw new DepotGarantieNotFoundException(Erreur SQL, e);
}
finally {
try {
if (result != null) {
result.close();
result = null;
}
if (oCmd != null) {
oCmd.close();
oCmd = null;
}
if (myConnection != null) {
myConnection.close();
myConnection = null;
}
} catch (SQLException e) {}
}
Guillaume de Vinzelles
DSI/PFS Neuf Cegetel
Altran Technologies
[EMAIL PROTECTED]
01 70 18 21 64
-Message d'origine-
De : Christopher Schultz [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 11 octobre 2006 16:20
À : Tomcat Users List
Objet : Re: JDBC Pool exhaustion
Guillaume,
Resource name=jdbc/Signup auth=Container
type=javax.sql.DataSource
driverClassName=oracle.jdbc.driver.OracleDriver
The Tomcat manager shows around 1000 sessions on the server, which
seems to be pertinent.
What is your connection allocation strategy? Meaning: do you allocate a
Connection object to each session for the life of the session, or do you
use some kind of pooling mechanism and only fetch Connection objects
when you need to execute a query?
If you associate a Connection with each session, I would strongly
recommend that you use pooling as described above.
If you are already using pooling (which it looks like you /are/ given
your configuration), then you might have a connection leak in one or
more places.
How are you actually getting and releasing your connections?
We can see with the JMXProxy that the JDBC pool connections are never
recycled, e.g. the active connections number is going higher and
higher and never stays at the same level, which is strange because
the amount of active sessions isn't growing.
Does your connection count grow larger than 150 (your maxActive number)?
Perhaps you really do need that number of connections if you have 1000
sessions.
Do you have any idea about what we can do to 'force' the Tomcat
server to release the unused JDBC connections?
Tomcat isn't in charge of your connections... the Oracle driver is.
You'd have to look at how they are being used.
-chris
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: JDBC Pool exhaustion
I will consider this option, thanks !
Guillaume de Vinzelles
DSI/PFS Neuf Cegetel
Altran Technologies
[EMAIL PROTECTED]
01 70 18 21 64
-Message d'origine-
De : Mikolaj Rydzewski [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 11 octobre 2006 16:46
À : Tomcat Users List
Objet : Re: JDBC Pool exhaustion
DE VINZELLES, Guillaume (ext.) wrote:
finally {
try {
if (result != null) {
result.close();
result = null;
}
if (oCmd != null) {
oCmd.close();
oCmd = null;
}
if (myConnection != null) {
myConnection.close();
myConnection = null;
}
} catch (SQLException e) {}
}
You use plain JDBC calls. Have you considered jakarta commons dbutils
here? It simplifies a lot: no more need to do nasty finally{} calls.
--
Mikolaj Rydzewski [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: JDBC Pool exhaustion
Wow, thanks for all those advices, we're going to clean up our code following
your guidelines. I'll also check the Oracle driver capabilities. Hope it will
fix our problem.
Thanks again!
Guillaume de Vinzelles
DSI/PFS Neuf Cegetel
Altran Technologies
[EMAIL PROTECTED]
01 70 18 21 64
-Message d'origine-
De : Christopher Schultz [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 11 octobre 2006 16:55
À : Tomcat Users List
Objet : Re: JDBC Pool exhaustion
Guillaume,
For Christopher and Alberty, here is an example of how we connect to the
database.
I'm quite sure we are using the JDBC pool.
From your DataSource configuration, it looks like you are using the
Oracle driver directly. Does that have built-in pooling? If not, it
looks like you might be creating a new connection every time. Sorry, I'm
totally ignorant of the Oracle driver capabilities.
Connection myConnection = null;
CallableStatement oCmd = null;
ResultSet result = null;
try {
/* SNIP */
}
catch (Exception e) {
logger.error(e.getMessage(), e);
throw new DepotGarantieNotFoundException(Erreur SQL, e);
}
finally {
try {
if (result != null) {
result.close();
result = null;
}
if (oCmd != null) {
oCmd.close();
oCmd = null;
}
if (myConnection != null) {
myConnection.close();
myConnection = null;
}
} catch (SQLException e) {}
}
Although this is probably okay, it's not air tight. You should change
your finally clause to this:
finally {
if (result != null) try { result.close(); }
catch (SQLException e) { logger.error(:(, e); }
if (oCmd != null) try { oCmd.close(); }
catch (SQLException e) { logger.error(:(, e); }
if (myConnection != null) try { myConnection.close(); }
catch (SQLException e) { logger.error(:(, e); }
}
This will attempt to close each resource separately, so if there is some
kind of exception causing your ResultSet to fail to close, you still
have a chance at closing the statement and connection.
Also, I saw that you were swallowing the SQLException at the end of the
finally block. This is a mistake, as you'll never know when you have a
problem! You should always log exceptions if they occur. You never
know... you might be getting exceptions all the time which would lead
you to your connection leak, but never know it because they are being
ignored.
All of the database code in my projects goes into several service
classes to isolate it from the rest of the code. All of the service
classes extend from a BaseService which has the following method:
protected void close(ResultSet rs, PerparedStatement ps,
Connection conn)
{
if (rs != null) try { rs.close(); }
catch (SQLException e) { logger.error(:(, e); }
if (ps != null) try { ps.close(); }
catch (SQLException e) { logger.error(:(, e); }
if (conn != null) try { conn.close(); }
catch (SQLException e) { logger.error(:(, e); }
}
This helps me by putting all of this code together in one place (in case
I needed to change it for whatever reason), and making the methods that
use JDBC a little cleaner because the finally block becomes:
finally
{
super.close(rs, ps, conn);
}
I'm not sure if this will help you too much, but it's an idea that I
have always used.
On a final note, you should be careful when using pooled connections and
transactions. If you don't handle rollbacks properly, you can (at least
with the Jakarta Commons DBCP) end up committing transactions that
should have been rolled back (yikes!).
You need to make sure that you catch /everything/ that can occur, like this:
catch (SQLException) (obvious)
catch (anything in the throws clause of your method)
catch (java.lang.Error)
catch (java.lang.RuntimeException)
This doesn't have anything to do with connection leaks, really, but I
figured I'd mention it.
-chris
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: JDBC Pool exhaustion
Thanks a lot all of you! I'll keep you posted. Guillaume de Vinzelles DSI/PFS Neuf Cegetel Altran Technologies [EMAIL PROTECTED] 01 70 18 21 64 -Message d'origine- De : Martin Gainty [mailto:[EMAIL PROTECTED] Envoyé : mercredi 11 octobre 2006 17:16 À : Tomcat Users List Objet : Re: JDBC Pool exhaustion If you have 1000 connections then you would be well advised to use connection pooling more specifically you need to separate the activities of settingup a connection from getting the connection you also need to separate the activities of freeing the connection from connection teardown connection setup and teardown are expensive operations and should be used judiciously continous connection setup and teardown will not only bog down the app but slow the DB as it furiously tries to keep up with these resource requests A vert good primer for setting up connection pools is available at http://www.webdevelopersjournal.com/columns/connection_pool.html A word on SEH for non oo single threaded environments you may swallow the exception if you have deemed the execution of the statement as optional If the statement is required then I would always raise a meaningful exception and not swallow it If you have a OO env such as Java you should raise the exception and handle it by the outermost handler in a structured way (definition of SEH) as an aside I usually pass error_code and description Feel free to Contact me offline for particulars of how to implement, M- - Original Message - From: Christopher Schultz [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, October 11, 2006 10:54 AM Subject: Re: JDBC Pool exhaustion - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
