commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Anderson" <...@netspace.net.au>
Subject RE: [DBCP] cpdsadapter needs a Statement implementation
Date Mon, 07 Jul 2003 04:00:59 GMT
On the subject of logging, are there any plans to implement
SQL traces? I have a hacked copy of dbcp which I used
to help track down a deadlock. If there's any interest,
I'll clean it up and submit it.

Regards,

Tim

> -----Original Message-----
> From: David Graham [mailto:grahamdavid1980@yahoo.com]
> Sent: Monday, 7 July 2003 1:51 PM
> To: Jakarta Commons Developers List
> Subject: Re: [DBCP] cpdsadapter needs a Statement implementation
>
>
> --- John McNally <jmcnally@collab.net> 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>



---------------------------------------------------------------------
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