You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by John McNally <jm...@collab.net> on 2003/07/06 22:17:41 UTC
[DBCP] cpdsadapter needs a Statement implementation
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.
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.
john mcnally
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re[2]: [DBCP] cpdsadapter needs a Statement implementation
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello John!
JM> In jdbc2+, a connection pool would not normally wrap a DataSource or
JM> Driver. The specification is written so that vendors supply a
JM> ConnectionPoolDataSource (CPDS) which would normally be used by a
JM> pooling DataSource.
JM> Jdbc2PoolDataSource is written to use a CPDS. I created
JM> DriverAdapterCPDS, so that it can still be used with jdbc
JM> implementations that do not yet implement the newer specification.
BTW (OT), it would be nice to clearly formulate the advice of
which to use: vendor-provided CPDS or CPDSAdapter over the
old jdbc driver?
For instance I have been long wondering (and still am)
what is better for MySQL, for instance.
If the advice is to prefer (for any reason) the vendor
provided CPDS over jdbc1 driver wrapped into CPDSAdapter
it would be nice to state this in the docs.
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] cpdsadapter needs a Statement implementation
Posted by John McNally <jm...@collab.net>.
On Sun, 2003-07-06 at 20:51, David Graham wrote:
> --- John McNally <jm...@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.
>
In jdbc2+, a connection pool would not normally wrap a DataSource or
Driver. The specification is written so that vendors supply a
ConnectionPoolDataSource (CPDS) which would normally be used by a
pooling DataSource.
Jdbc2PoolDataSource is written to use a CPDS. I created
DriverAdapterCPDS, so that it can still be used with jdbc
implementations that do not yet implement the newer specification.
The jdbc2 specification for a Connection object returned by
CPDS.getPooledConnection().getConnection() is that it should always
return a new object, only one should be open at any given time, and
after Connection.close() is called that object is no longer usable.
john mcnally
john mcnally
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [DBCP] cpdsadapter needs a Statement implementation
Posted by Tim Anderson <tm...@netspace.net.au>.
Very cool - thanks for the link.
> -----Original Message-----
> From: Serge Knystautas [mailto:sergek@lokitech.com]
> Sent: Monday, 7 July 2003 2:31 PM
> To: Jakarta Commons Developers List
> Subject: Re: [DBCP] cpdsadapter needs a Statement implementation
>
>
> Tim Anderson wrote:
> > 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.
>
> I think the sense moving forward is that DBCP will remain only a pooling
> implementation, and leave other responsibilities to other libraries.
>
> The open source mac-daddy of SQL tracing is at www.p6spy.com. Great for
> tracking deadlocks and slow spots. There's even a recent add-on that
> will analyze all the SQL tracing and suggest indexes for tables.
>
> --
> Serge Knystautas
> President
> Lokitech >> software . strategy . design >> http://www.lokitech.com/
> p. 1.301.656.5501
> e. sergek@lokitech.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
Re: [DBCP] cpdsadapter needs a Statement implementation
Posted by Serge Knystautas <se...@lokitech.com>.
Tim Anderson wrote:
> 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.
I think the sense moving forward is that DBCP will remain only a pooling
implementation, and leave other responsibilities to other libraries.
The open source mac-daddy of SQL tracing is at www.p6spy.com. Great for
tracking deadlocks and slow spots. There's even a recent add-on that
will analyze all the SQL tracing and suggest indexes for tables.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com/
p. 1.301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [DBCP] cpdsadapter needs a Statement implementation
Posted by Tim Anderson <tm...@netspace.net.au>.
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 <jm...@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
Re: [DBCP] cpdsadapter needs a Statement implementation
Posted by David Graham <gr...@yahoo.com>.
--- John McNally <jm...@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