RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keepincreasing....
Right, since I seem to be the only alien having this problem I would be happy to know how you write jdbc classes and (if any) a datasource manager. Do you create a separate class for retrieving connections or datasources. Are the methods static. How do your dao's code look like? For example when using a connection, statement, resultset. How and where do you close them, and do you return values afterwards. Do you use the factory pattern? Any code examples, step by step guide of something that works would be very helpful. Basically, a great step by step tutorial would be more helpful than trying to spot my problem as everyone seems to have a different opinion from the other. Frankly speaking, I believe there is no sufficient and a spot-on-clear documentation of what thread safe servlet containers really mean and the usage of static methods on these servlet containers. The current documentation can be understood in many different ways. What interests me more about this thread is that many people suggested to avoid using static methods in web applications. Avoiding static methods for DAO's is understandable, but avoiding static methods for retrieving a datasource seems strange. I have seen millions (if not zillions) code examples on the net where static methods are used for retrieving datasources. So I would be happy to see how others write code without static methods. Thanks, Sinoea From: [EMAIL PROTECTED] To: users@tomcat.apache.org Date: Wed, 17 Sep 2008 22:26:16 -0500 Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keepincreasing From: sinoea kaabi [mailto:[EMAIL PROTECTED] Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keepincreasing I could accept the fact that we should create new objects of Dao's, but for getting a datasource or connection it should make sense to have a utility class with static methods. Absolutely - Johnny K's suggestion of doing a new every time is utter nonsense. So is a connection a thread-safe object or not? No, a connection is not thread-safe: it is designed to be be used by only one thread at a time. If you have multiple threads accessing a connection object *simultaneously*, you will have problems. On the other hand, connection managers (e.g., the commons-dbcp code) are thread-safe; multiple threads may call one simultaneously to acquire connection objects, and each thread is guaranteed to be given a separate object. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Make a mini you and download it into Windows Live Messenger http://clk.atdmt.com/UKM/go/111354029/direct/01/ - 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 5.5, JNDI Connection Pooling, Active connections keepincreasing....
- Original Message - From: Caldarale, Charles R [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, September 18, 2008 5:26 AM Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keepincreasing From: sinoea kaabi [mailto:[EMAIL PROTECTED] Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keepincreasing I could accept the fact that we should create new objects of Dao's, but for getting a datasource or connection it should make sense to have a utility class with static methods. Absolutely - Johnny K's suggestion of doing a new every time is utter nonsense. --- I eat humble pie you right... completely off track... One of the problems is that I'm not thinking framework... and sinoea is in one. Also not having used DBCP I'm at a disadvantage here... maybe should just shut the hell up... As I see it... sinoea is creating a singleton... to hold that data source... he has to because the control servlet is inside a framework, so he is holding a pool from the fridge of the framework... So... struts people... just help this guy... Does struts have a better built in way to manage the pool... so he can just get the reference to it? If not... what is standard practice for using a third party pool in the struts framework... He's into holding stuff in statics... because he is trying to keep a single instance of the pool available to all the rest of his action objects... Thats what he's asking... what is the right way to do that in struts like maybe its standard practice to hold DHCP in a servlet context attribute... or maybe struts has a really clever way of doing that for you... thats the question? ... my suggestions do suck... what is the right way in struts to hold that 3rd party pool dish out references where they needed ? --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- - 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 5.5, JNDI Connection Pooling, Active connections keepincreasing....
Struts datasource usage is deprecated, they encourage users not to try their datasource configuration in the xml. Instead I was advised to manually configure JNDI connection pooling with Struts. From: [EMAIL PROTECTED] To: users@tomcat.apache.org Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keepincreasing Date: Thu, 18 Sep 2008 12:04:11 +0200 - Original Message - From: Caldarale, Charles R [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, September 18, 2008 5:26 AM Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keepincreasing From: sinoea kaabi [mailto:[EMAIL PROTECTED] Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keepincreasing I could accept the fact that we should create new objects of Dao's, but for getting a datasource or connection it should make sense to have a utility class with static methods. Absolutely - Johnny K's suggestion of doing a new every time is utter nonsense. --- I eat humble pie you right... completely off track... One of the problems is that I'm not thinking framework... and sinoea is in one. Also not having used DBCP I'm at a disadvantage here... maybe should just shut the hell up... As I see it... sinoea is creating a singleton... to hold that data source... he has to because the control servlet is inside a framework, so he is holding a pool from the fridge of the framework... So... struts people... just help this guy... Does struts have a better built in way to manage the pool... so he can just get the reference to it? If not... what is standard practice for using a third party pool in the struts framework... He's into holding stuff in statics... because he is trying to keep a single instance of the pool available to all the rest of his action objects... Thats what he's asking... what is the right way to do that in struts like maybe its standard practice to hold DHCP in a servlet context attribute... or maybe struts has a really clever way of doing that for you... thats the question? ... my suggestions do suck... what is the right way in struts to hold that 3rd party pool dish out references where they needed ? --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Make a mini you and download it into Windows Live Messenger http://clk.atdmt.com/UKM/go/111354029/direct/01/
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keepincreasing....
- Original Message - From: sinoea kaabi [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, September 18, 2008 1:24 PM Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keepincreasing Struts datasource usage is deprecated, they encourage users not to try their datasource configuration in the xml. Instead I was advised to manually configure JNDI connection pooling with Struts. Ah... the thlot pickens --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- - 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 5.5, JNDI Connection Pooling, Active connections keepincreasing....
The datasource object is threadsafe and a prime example of the factory
pattern. In my designs, I tend to retrieve a reference to it early on
and then store it somewhere convenient for the life of the request.
Then each db access method get's a connection, uses it and closes it
before returning. I'm also a fan of the architecture Chris Shultz
posted (only one try catch w/ try/catches in the finally block for each
db object):
try {
// get connection
// do something
} catch ( exception e ) {
// log or otherwise handle the error
// I tend to wrap the exception and rethrow it in a higher level
exception
} finally {
try { resultset.close() ; } catch (exception e1) {}
try { statement.close() ; } catch (exception e2) {}
try { connection.close() ; } catch (exception e3) {}
}
return ...
Obviously I'm being really terse here, but I think you see the general
idea. As an overall pattern, I tend to encapsulate db access in a small
number of methods like the one above, leaving the remainder of the
project free to work with beans/arrays/hashtables/whatever.
I also like Chris' ideas regarding how to diagnose the issue -- drop the
pool size down really small and see if the pool get's exhausted. What
you are seeing may be some wierd artifact of how DBCP manages it's
connection pool.
--David
sinoea kaabi wrote:
Right, since I seem to be the only alien having this problem I would
be happy to know how you write jdbc classes and (if any) a datasource manager.
Do you create a separate class for retrieving connections or datasources.
Are the methods static.
How do your dao's code look like?
For example when using a connection, statement, resultset. How and where do
you close them, and do you return values afterwards.
Do you use the factory pattern?
Any code examples, step by step guide of something that
works would be very helpful.
Basically, a great step by step tutorial would be more helpful than trying to
spot my problem as
everyone seems to have a different opinion from the other.
Frankly speaking, I believe there is no sufficient and a spot-on-clear
documentation
of what thread safe servlet containers really mean and the usage of static
methods
on these servlet containers.
The current documentation can be understood in many different ways.
What interests me more about this thread is that many people suggested to
avoid using
static methods in web applications.
Avoiding static methods for DAO's is understandable, but avoiding static
methods for retrieving a datasource
seems strange.
I have seen millions (if not zillions) code examples on the net where static
methods are used for retrieving
datasources.
So I would be happy to see how others write code without static methods.
Thanks,
Sinoea
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Date: Wed, 17 Sep 2008 22:26:16 -0500
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections
keepincreasing
From: sinoea kaabi [mailto:[EMAIL PROTECTED]
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active
connections keepincreasing
I could accept the fact that we should create new objects of Dao's,
but for getting a datasource or connection it should make sense
to have a utility class with static methods.
Absolutely - Johnny K's suggestion of doing a new every time is utter
nonsense.
So is a connection a thread-safe object or not?
No, a connection is not thread-safe: it is designed to be be used by only
one thread at a time. If you have multiple threads accessing a connection
object *simultaneously*, you will have problems. On the other hand,
connection managers (e.g., the commons-dbcp code) are thread-safe; multiple
threads may call one simultaneously to acquire connection objects, and each
thread is guaranteed to be given a separate object.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Make a mini you and download it into Windows Live Messenger
http://clk.atdmt.com/UKM/go/111354029/direct/01/
-
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
RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keepincreasing....
From: sinoea kaabi [mailto:[EMAIL PROTECTED] Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keepincreasing I could accept the fact that we should create new objects of Dao's, but for getting a datasource or connection it should make sense to have a utility class with static methods. Absolutely - Johnny K's suggestion of doing a new every time is utter nonsense. So is a connection a thread-safe object or not? No, a connection is not thread-safe: it is designed to be be used by only one thread at a time. If you have multiple threads accessing a connection object *simultaneously*, you will have problems. On the other hand, connection managers (e.g., the commons-dbcp code) are thread-safe; multiple threads may call one simultaneously to acquire connection objects, and each thread is guaranteed to be given a separate object. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
