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(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)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(a)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(a)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(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)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(a)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(a)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@jboss.org]
>> Sent: Thursday, October 12, 2006 12:53 PM
>> To: Vladimir Blagojevic
>> Cc: jbosscache- dev(a)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(a)jboss.org
>> Telephone: +44 7786 702 706
>> MSN: manik(a)surtani.org
>> Yahoo/AIM/Skype: maniksurtani
>
> _______________________________________________
> jbosscache- dev mailing list
> jbosscache- dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jbosscache- dev
>