DO NOT REPLY [Bug 17677] New: - Pooled connection architecture vulnerable to double use

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17677>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17677

Pooled connection architecture vulnerable to double use

           Summary: Pooled connection architecture vulnerable to double use
           Product: Commons
           Version: 1.4 Final
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Dbcp
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: flawlor@athensgroup.com


There are several circumstances where two different pieces of code can be 
inadvertently sharing the same connection.  Obviously this is a serious 
problem.  Oftentimes this manifests itself as an error about the connection 
suddenly becoming closed, in an invalid state, etc.  Notice how often these 
symptoms are reported in various forums when people start using connection 
pools.

In a transactional environment this can be especially serious since either of 
the users of the connection may commit it while the other has made partial 
updates.  This can easily lead to corruption of the database.

Debugging this problem is especially difficult since it may only appear 
intermittently and under load.  It can be very difficult to reproduce for 
debugging.  This is even more of a problem when connections are closed in 
finalize() methods (a common practice) because of their asynchronous and 
delayed behavior.

There is a fundamental architectural flaw which makes this all possible.  When 
a pooled connection (e.g., org.apache.commons.dbcp.PoolableConnection) is 
returned to the pool, the very same instance is later handed out.  Note that 
this is not necessary for reuse of the underlying real connection (e.g.,  
java.sql.Connection).  A new wrapper class could be instantiated around the 
existing real connection and the old one discarded.  Because the same wrapper 
class instance is handed out multiple times, it makes it possible for 
inadvertent sharing to occur.

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