Well, the shrinking is *kind of* the same thing. It will release
unused connections from the pool over time, so the pool doesn't stay
unnaturally bloated after peak usage. However, it doesn't make any
particular guarantees about which connections will be released when.
Instead of implementing a different timeout, I think I'll just
recast the "shrinking" as an idle timeout. Instead of releasing a
fraction of unused connections, it will just remove all connections that
are over the idle timeout, and perhaps replace some if more than 20-30% of
the pool is released in that manner.
GC is mostly useless in the J2EE environment, where everything is
very transaction oriented and you wouldn't expect a connection to be out
of the pool for more than a few ms. It's mostly aimed at other
environments where you might check a connection out of the pool for a long
period of time.
Aaron
On Thu, 14 Sep 2000, Chris Audley wrote:
> There reaches a point where the overhead of checking the connection to the
> database is on the same order of magnitude as just opening a new connection.
> If you're reading metadata and doing queries, I think you've reached that
> point. You might as well just ditch connection pooling.
>
> I think object timeouts are the way to go. Not only do they clear out
> connections that may have gone stale, but with commercial RDBMS, you pay for
> concurrent connections. Idle pooled connections waste money.
>
> I was actually surprised to find out that Minerva didn't provide a timeout
> for pooled objects. All of the mechanics are there, the last time an object
> was used is reported and a GC thread is run periodically. All thats needed
> is a stale object timeout ( there are already two, I though GCMinIdleTime
> was cleaning out stale objects ), and the logic in the GC method.
>
> Cheers
> Chris Audley
> Urbanfetch.com
>
> -----Original Message-----
> From: Aaron Mulder [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 14, 2000 12:03 PM
> To: jBoss
> Subject: Re: [jBoss-User] JDBC Connection reset by peer
>
>
> That's not going to work either. For one thing, it might take
> some effort to locate a table the user has select privileges on (we can't
> really tell an access denied SQLException from a collection to DB lost
> SQLException). But more importantly, I've seen Oracle instances that were
> so bloody complex that it took minutes to load the database metadata.
> Now you might argue that that represents poor database design, but it's
> not up to you.
> We could maybe let the user specify a table and then execute a
> "select 'x' from foo where 0=1" or something. But I kind of liked the
> other idea about just timing out the connections if they've been idle too
> long.
>
> Aaron
>
> On Thu, 14 Sep 2000, Rick Horowitz wrote:
> > I'm not 100% sure of the problem you're trying to solve here, but would
> > it be possible to use one of the JDBC connections to read the database
> > metadata, and from that create a JDBC query that could be executed to,
> > for example, just read some data from one of the tables?
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
