[jbosscache-dev] Using Apache DBCP in NonManagedConnectionFactory

Manik Surtani manik at jboss.org
Mon Oct 16 06:15:23 EDT 2006


Not just that it won't be closed, but every new non-tx call will  
attempt to create a new conn.  Every time.  And this sux.  :-)  Hence  
the need for a conn pool.
--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat

Email: manik at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani


On 12 Oct 2006, at 19:04, Hany Mesha wrote:

> The connection gets created by the prepare method which is called  
> from within a transaction context and then the tx calls the commit  
> method which commits or rolls back the changes and closes the  
> connection in the end. On the other hand, If the connection is used  
> outside the tx context then it might be leaking as you described  
> since there's no guarantees that it'll be closed.
>
> Hany
>
>
>
>
> Hany M. Mesha
> Sr. Software Engineer, Consultant
> Novell Identity Management Engineering
> Toronto, Canada
> hmesha at novell.com
> Mobile: 416-456-6945
> skype: hanymesha
>
> Novell, Inc.
> SUSE® Linux Enterprise 10
> Your Linux is ready
> http://www.novell.com/linux
>
>
>
>
>>>> Manik Surtani <manik at jboss.org> 10/12/06 1:34 PM >>>
> In that case it shouldn't be creating its own connections!  :- )  It
> becomes a conn leak when put under load.
>
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik at jboss.org
> Telephone: +44 7786 702 706
> MSN: manik at surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
> On 12 Oct 2006, at 18:27, Hany Mesha wrote:
>
>> The name of the class says it all "NonManagedConnectionFactory".
>> It's meant to be managed by a transaction. If the user is looking
>> to manage the connection himself either with a custom connection
>> pooling or otherwise, he/she should be looking at using
>> ManagedConnectionFactory and vendor specific implementation of
>> that. I know that Oracle, Derby and perhapes the rest of the DB
>> vendors provide implementation for managed connection factories to
>> handle concurrency situations such as this one.
>>
>> - Hany
>>
>>
>>
>>
>>
>>
>> Hany M. Mesha
>> Sr. Software Engineer, Consultant
>> Novell Identity Management Engineering
>> Toronto, Canada
>> hmesha at novell.com
>> Mobile: 416- 456- 6945
>> skype: hanymesha
>>
>> Novell, Inc.
>> SUSE® Linux Enterprise 10
>> Your Linux is ready
>> http://www.novell.com/linux
>>
>>
>>
>>
>>>>> "Vladimir Blagojevic" <vladimir.blagojevic at jboss.com> 10/12/06
>>>>> 1:01 PM >>>
>> Never underestimate people's stupidity, like me for example. On a  
>> more
>> serious note, can this pooling be isolated and then use  
>> interchangable
>> pooling implementations? How does hibernate make it interchangable?
>> They
>> must be using some adaptation layer?
>>
>> My main point is to see what they have done and not reinvent the
>> wheel.
>>
>>> -----  Original Message-----
>>> From: Manik Surtani [mailto:manik at jboss.org]
>>> Sent: Thursday, October 12, 2006 12:53 PM
>>> To: Vladimir Blagojevic
>>> Cc: jbosscache-  dev at lists.jboss.org
>>> Subject: Re: [jbosscache-  dev] Using Apache DBCP in
>>> NonManagedConnectionFactory
>>>
>>> I doubt anyone would use a cache loader if JBC is a cache for
>>> Hibernate.  :-  )
>>>
>>> This is more for standalone cases, not even within an app
>>> server since then the app server would provide db conn pooling.
>>> --
>>> Manik Surtani
>>>
>>> Lead, JBoss Cache
>>> JBoss, a division of Red Hat
>>>
>>> Email: manik at jboss.org
>>> Telephone: +44 7786 702 706
>>> MSN: manik at surtani.org
>>> Yahoo/AIM/Skype: maniksurtani
>>
>> _______________________________________________
>> jbosscache-  dev mailing list
>> jbosscache-  dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-  dev
>>
>
>





More information about the jbosscache-dev mailing list