--- John McNally <[EMAIL PROTECTED]> wrote:
> I recently noticed that the cpdsadapter package needs to be fixed wrt
> the Statement.getConnection() method.  It will currently return the
> underlying physical Connection object as opposed to the logical
> Connection which was used to create the Statement.

Can you explain the uses of the cpdsadapter classes?  Having multiple
implementations like this seems counter productive.

> 
> When first writing cpdsapapter, I determined that using
> DelegatingConnection was not possible as it allowed reopening of a
> closed Connection.  The code in jdbc2pool and cpdsadapter attempts to be
> fully jdbc2 (or later) compliant and the specification requires that a
> Connection object be unusable after close() is called.  Now cpdsadapter
> needs a Statement implementation which will require a ResultSet
> implementation.  Taking another look at DelegatingConnection, it could
> be used as the base class for a jdbc2 compliant Connection as long as
> the child class creates a no-op for the activate method.  Does anyone
> see a problem with that approach?
> 
> The only problem I have with going that route is the situation regarding
> the abandoned connection code.  I thought it was already agreed that
> this code would be removed many months ago, but I am seeing revived
> debate and the possibility of retaining some of the code for possible
> logging.

The abandoned related code will be removed and any logging will be new
code.

David

> 
> john mcnally
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to