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 additiona
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keepincreasing....
- Original Message - From: "sinoea kaabi" <[EMAIL PROTECTED]> To: "Tomcat Users List" 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....
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" > 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: "Caldarale, Charles R" <[EMAIL PROTECTED]> To: "Tomcat Users List" 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....
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....
> 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]