« Return to Thread: Keep alive JDBC Connection Pool

Re: Keep alive JDBC Connection Pool

by Trinath :: Rate this Message:

| View in Thread

Hi Brett,
  I might be able to work around my problem with this setting however my requirement is a bit different from yours.
   My requirement is: Keeping alive the connections in pool for ever (or until the servers are bounced) and if they happen to break for any reason like DB crash, network/firewall dropping the connections, they need to be resusicated to the min pool level.
   In this way, I am always guarenteed a connection and a valid one if I turn on 'testQuery' (until ofcourse I run out of pool i.e. all connections in pool are in use).
   Hope I am clear.
 
Regards,
Trinath

Brett Wooldridge-2 wrote:
Trinath,

I have a question.  I'm a developer who works on BTM, and I've added a
feature to an experimental branch of bitronix.  I was wondering if this
feature
might help in your case.

In my case, my company uses Bitronix in combination with Apache Derby.
Derby has a limitation that all temporary tables are in-memory, and the
resources are not freed until the connection the temporary tables was
created on is closed.  This obviously causes a problem with connection
pools.  Connections that are never closed, but are used for long periods of
time, eventually consume ever increasing amounts of memory.

In order to work around this issue, I have been experimenting with a new
bitronix setting to configure a "maximum lifetime" on a database connection.
Connections in the idle state, but which exceed the maximum lifetime are
closed (and the pool is refilled up to the minimum level).  Note this is
different
from an "idle timeout".  In our system, there is constant activity, which
keeps
connections in the pool from ever reaching the standard idle timeout
threshold.

But with this new setting, if you configured a maximum lifetime for a
connection of
30 minutes, it would be closed if it had lived more than 30 minutes, even
if it was
only idle for 30 seconds.

If this setting would be useful to you, and it sounds like it might, I can
look at
merging the change over into the trunk.  I've been intending do to it,
because it is
essential for anyone using Derby and temporary tables, but there hasn't
been an
urgency to do so.

Brett

On Thu, Apr 5, 2012 at 7:35 PM, Trinath <trinathm@techmahindra.com> wrote:

>
> Sir,
>   Do we have the keepAlive functionality available yet (after two years)?
> This is a persistent problem and all along we have been working around it.
>
>  The problem we have is, once we hit the limit, there is no way we can get
> a valid connection. So it would really help if a functionality is provided
> where once Bitronix reaches the upper limit, it will reclaim all invalid
> connections and re-create valid connection(s) to hand over to the
> requestor(s).
>
> Regards,
> Trinath
>
>
> Trinath wrote:
> >
> >
> > Ludovic Orban wrote:
> >>
> >> It's not the DB which is killing the connections but the problem is
> >> basically the same: idle connections are dropped so why not configuring
> >> the min pool size to 0 to have them expire before your proxy/firewall
> >> kills them?
> >>
> >> I could implement some connection keepalive mechanism but that won't
> >> happen anytime soon so you'd still have to find a workaround in the
> >> meantime.
> >>
> > I think then this negates the concept of connection pooling and will lead
> > to increased response times. I will be looking forward to your keepalive
> > implementation whenever it comes.
> > Just want to add that I have worked around this problem by setting
> > acquistioninterval to 0sec and acquisitiontimeout to 300sec.
> >
>
> --
> View this message in context:
> http://old.nabble.com/Keep-alive-JDBC-Connection-Pool-tp27420030p33568802.html
> Sent from the Bitronix Transaction Manager mailing list archive at
> Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

 « Return to Thread: Keep alive JDBC Connection Pool