tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: DataSource configuration for production
Date Thu, 12 Jun 2008 20:58:25 GMT
I'll commit it later today.

-dain

On Jun 12, 2008, at 2:32 AM, jfjames wrote:

>
> OK, we've opened a DBCP JIRA issue :
> https://issues.apache.org/jira/browse/DBCP-269.
>
> It would be very nice to include this patch in OpenEJB 3.0.1.
>
> -JF
>
>
> David Blevins wrote:
>>
>>
>> On Jun 11, 2008, at 4:44 AM, jfjames wrote:
>>
>>>
>>> We're back ... It seems we’ve identified the cause of the problem.
>>> It is
>>> located in DBCP 1.3. In fact, the isClosed method of the
>>> DelegatingConnection class doesn’t really close the underlying JDBC
>>> connection  :
>>> * when called from the destroyObject method of the
>>> PoolableConnectionFactory, the _closed  variable is set to false,
>>> * therefore the test if ( _closed || _conn.isClosed() ) doesn’t
>>> allow to
>>> propagate the close along the delegating chain (up to the JDBC
>>> connection).
>>>
>>> According to us, it should be replaced by if ( _closed &&
>>> _conn.isClosed()
>>> ). We’ve done some tests with this patch and it works fine :
>>> maxActive is
>>> never exceeded and the number of connections to the database  
>>> server is
>>> stable.
>>>
>>> Now, we have to check the impact on the DBCP jUnit tests before  
>>> going
>>> further ...
>>
>> Great work!  Going to be a fantastic contribution.
>>
>> Once you're confident on the impact to the dbcp unit tests, craft  
>> up a
>> patch file and open up a JIRA for the issue at
>> http://issues.apache.org/jira/browse/DBCP
>> I can help you with instructions on creating patches if you need it
>> (just an "svn diff > myPatch.txt" for the most part).  Then I can go
>> tap those guys on the shoulder and let em know we're waiting on it  
>> and
>> it's critical for us.
>>
>> If we can get them to commit it we won't need to wait for a DBCP
>> release and can just roll up a custom build that we can use in 3.0.1.
>>
>> -David
>>
>>
>>> jfjames wrote:
>>>>
>>>> We've spent some time today investigating what actually happens in
>>>> the
>>>> DataSource ... Not so easy since DBCP code is a little tricky !
>>>>
>>>> We've observed that JDBC connections which are realeased from the
>>>> pool by
>>>> the Evictor are not physically closed :
>>>> 1/ from the DataSource standpoint : the maximum size of the pool is
>>>> never
>>>> exceeded (numActive is always inferior to maxActive),
>>>> 2/ but from the dataserver standpoint : the number of connections  
>>>> is
>>>> always increasing (up to the maximum allowed by the server).
>>>>
>>>> We haven't identified the exact cause of this issue : for some
>>>> unknown
>>>> reason the DelegatingConnection.close() method consider the JDBC
>>>> connection as already closed which is wrong.
>>>>
>>>> Next step tomorrow ...
>>>>
>>>
>>> -- 
>>> View this message in context:
>>> http://www.nabble.com/DataSource-configuration-for-production-tp17695975p17775606.html
>>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>
> -- 
> View this message in context: http://www.nabble.com/DataSource-configuration-for-production-tp17695975p17796021.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>


Mime
View raw message