commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <grahamdavid1...@yahoo.com>
Subject RE: [DBCP] AbandonedTrace - Connection Recovery
Date Wed, 23 Jul 2003 14:48:11 GMT
--- "Hope, Matthew" <Matthew.Hope@capitalone.com> wrote:
> 
> > -----Original Message-----
> > From: Glenn Nielsen [mailto:glenn@mail.more.net] 
> > Sent: 23 July 2003 13:52
> > To: Jakarta Commons Developers List
> > Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
> > 
> > 
> > Hope, Matthew wrote:
> > > I would disagree on one point. The idea of logging when a 
> > connection is
> > > closed due to garbage collection finalization strikes me as 
> > a good one
> > > (assuming the pool used is using a weakly referenced 
> > mapping otherwise
> > > garbage collection release of resources is going to be a 
> > real bummer).
> > > 
> > 
> > Using GC to log or recover an abandoned connection won't work 
> > because the
> > connection is a member of the pool and will never be eligible for GC.
> > 
> > Glenn
> 
> I feel you may have missed my comment above to the effect that the pool
> is
> using a weakly referenced map.

Using a WeakHashMap might be a good solution.  Connections are guaranteed
to be closed when they are garbage collected so if a client doesn't return
a connection and loses all pointers to it, the pool would lose its
reference to it and the Connection would get gc'd.  This is *much* better
than grabbing a connection away from the client application that may still
be using it.

What would happen to the connection when it gets closed by garbage
collection though?  Since it's a pooled connection, calling close() tries
to return it to the pool but the pool lost its reference to the connection
when the client didn't return it.  How would the pool ensure the
connection originated from the pool?

David


> 
> In those circumstances garbage collection would free resources. I would
> think that their use is sensible so long as the pool can handle their
> garbage collection and get another one (though that may have the knock
> on
> effect of causing the getting of the connection to be synchronized to
> the
> client request - not a huge big deal in most cases but in a well managed
> resource environment such weak references would be unnecessary.
> 
> for an explanation see:
> http://java.sun.com/j2se/1.4.1/docs/api/java/lang/ref/WeakReference.html
> 
> Matt
>  
>
**************************************************************************
> The information transmitted herewith is sensitive information intended
> only
> for use by the individual or entity to which it is addressed. If the
> reader
> of this message is not the intended recipient, you are hereby notified
> that
> any review, retransmission, dissemination, distribution, copying or
> other
> use of, or taking of any action in reliance upon this information is
> strictly prohibited. If you have received this communication in error,
> please contact the sender and delete the material from your computer.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message