There are many issues that need to be discussed on this matter.
If we want to make the ConnectionPooling mechanism of Turbine
being compatible with JDBC2.0 we should actually re-write it.
More specifically:
1. The ConnectionPool class should not implement the
ConnectionPoolDataSource
interface (this is the job of the JDBC driver: to provide an implementation
of a
ConnectionPoolDataSource object).
2. The ConnectionPool class SHOULD implement the DataSource interface:
in order to do that, the getConnection() methods should return a Connection
and just throw SQLException (and not Exception). Now, it returns a
DBConnection objects and throws Exception.
BUT: the getConnection() method also throws the
ConnectionTimeoutException (which does not subclass the SQLException
but the Exception class), so the getConnection() cannot be modified
to throw SQLException.
3. The proper way to handle a ConnectionPool mechanism according
to the JDBC 2.0 is the following:
DataSource ds = <get somehow a datasource. eg. jndi>
//for us it could be:
DataSource ds = new ConnectionPool(...) or
DataSource ds = TurbinePoolServive.getDataSource()....
Connection c = ds.getConnection();
//use the connection
finally{
c.close();
}
That's all. Of course the c.close() does not actually close the connection
just returns it to the pool.
4. The DBConnection interface should NOT implement the PooledConnection
interface (again, this is the job of the JDBC driver which should create
PooledConnection objects through the ConnectionPoolDataSource).
5. The actual pooling in the ConnectionPool class should be done with
PooledConnection objects and not with DBConnection objects.
So, in order to make all the above work we should:
0. Implement it from scratch
1. Get rid of the DBConnection class
2. Change existing code to not call the TurbineDB.releaseConnection but
issue a connection.close() in a finally clause.
3. Extend each DB adapters to create ConnectionPoolDataSource objects
on request.
In order to support old jdbc drivers also we should:
1. Write an implementation of a PooledConnection interface to wrap the
Connection objects of the jdbc drivers that are not jdbc2.0 compliant.
2. Write an implementation of a ConnectionPoolDataSource interface
to wrap the above-mentioned (1) PooledConnection objects for driveras
that do no support jdbc 2.0
3. Get rid of DBConnection (the jdbc2.0 mechanism provides tracing
utils e.g. setLogWriter that can be used effectively).
You understand that all the above means lots of changes, testing and
also breaking existing code.
I need your opinions on the above.
The very good reason to do all these things (apart from being jdbc2.0
compliant) is:
1. JDBC connection recover by themselves in case of fatal errors.
2. Open resources (e.g. opened Statements) are automatically closed
when connection objects are returned to the pool
3. Use JNDI contexts
4. Be compatible with new specs.
Apart from that, as I mentioned in a previously e-mail, I changed the
existing code in a way that is compatible with the existing code,
uses both the new and the old way (if the driver is jdbc2.0 compliant)
and does work as is: BUT it is not the proper way to do it!!!
Give me your thoughts and comments.
P.S.
For once more, I wasn't able to make this diff -u so until I can do that,
you can propose me a way to upload the patched files for review, commit,
etc.
Costas
----- Original Message -----
From: "Jon Stevens" <[EMAIL PROTECTED]>
To: "Turbine" <[EMAIL PROTECTED]>
Sent: Tuesday, February 20, 2001 8:19 PM
Subject: Re: ConnectionPool ammendemends: JDBC 2.0 Compatibility & More
(2/2)
> on 2/19/01 11:02 PM, "K?staV Sterg?ou" <[EMAIL PROTECTED]> wrote:
>
> > P.S. I couldn't use the csv to upload the above code due to some
firewall
> > restrictions. Can you
> > please specify me the ports used for the Win-CVS client?
>
> Hi Costas.
>
> #1. You can download a daily snapshot from here:
> <http://www.working-dogs.com/daily/>
>
> Then just do a diff -u against that.
>
> #2. cvspserver 2401/tcp #CVS network server
>
> #3. Please line wrap your emails at less than ~76 columns. They are very
> hard to read because they are not line wrapped properly
>
> #4. I await your patches.
>
> thanks,
>
> -jon
>
> --
> If you come from a Perl or PHP background, JSP is a way to take
> your pain to new levels. --Anonymous
> <http://jakarta.apache.org/velocity/> && <http://java.apache.org/turbine/>
>
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
