Hi Costas,
(comments further down)
On Wed, Feb 21, 2001 at 12:59:57PM +0200, ??sta? Ste????? wrote:
> 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()....
This one looks like what we want to me.
> 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.
I'm +1 on all these changes - supporting the JDBC 2.0 API seems to have
several benefits - both in terms of the usability of our connection pool
elsewhere and the ability of Turbine apps to use an alternative pool if
appropriate (for instance running within a J2EE app server).
> 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.
However I wonder if you could look at doing this without actually
removing the existing APIs, but instead deprecating for instance
TurbineDB.getConnection() and TurbineDB.releaseConnection(). That way
existing apps don't break right now - but the warning is given that they
should be changed over to the JDBC 2.0 API way...
> 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.
+1 on changes and testing
-1 on breaking existing code right now (but deprecation warnings are
fine).
> 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!!!
Looking at the code and your comments, I think you can get closer to the
"proper" way of doing it, and keep a legacy compatibility layer - i.e.
have DBConnection merely wrap a PooledConnection implementation from the
driver, with its methods deprecated.
> 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.
Did you try diff -u against a nightly build as Jon suggested? What
happened there?
As these are much needed improvements, and you're willing to put the
work in, I'd be willing to review the code and commit it if it works for
me if either email me the new/amended classes or post the URL of a zip.
Posting the URL of a zip might be better, as then others can also review
the code.
Ideally though you'll get your diffs working... :-)
--
Sean Legassick
[EMAIL PROTECTED]
Je suis un homme: rien d'humain en m'est étranger
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
