tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: DataSource configuration for production
Date Thu, 12 Jun 2008 17:53:52 GMT

On Jun 12, 2008, at 10:07 AM, jfjames wrote:

>
> In parallel to this DBCP patch, I've developped an OpenEJB service  
> in order
> to use C3P0. My objective is to have a fallback solution in  
> production in
> case of problem with DBCP. Everything works fine (very good exercice  
> to
> understand how OpenEJB configuration works internally ... to be  
> honest I
> must admit there is still some mystery around XBean in my  
> understanding) ,
> except that no commit/rollback are sent to the database. This may be  
> due to
> the fact that C3P0 doesn't support distributed transaction and its
> connections are not enrolled by the TransactionManager (no  
> implementation of
> ManagedConnection). There is the same issue with Proxool. Do you  
> know any
> alternative to DBCP which could be used with OpenEJB ?

There's the Geronimo connection manager, but I'm not aware of anything  
else.  DBCP also didn't support any concepts related to transaction  
handling either and we had to add all that so we could use it in  
OpenEJB.  It was one of Dain's mini side efforts that took a few weeks.

Feel free to ask for xbean info of any kind on the dev list.

-David

> 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-tp17695975p17804966.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
>


Mime
View raw message