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 commands, e-mail: [EMAIL PROTECTED]
