on 1/2/2001 5:13 AM, "Rafal Krzewski" <[EMAIL PROTECTED]> wrote:
> Jon Stevens wrote:
>>> In our pool our conections implement java.sql.Connection, and they wrap
>>> the real connection, giving access to all methods (doing some check to
>>> see if the connection is available or not), except the close(), which
>>> does nothing. :-) Only the pool can access the close() method of the
>>> real connection.
>>>
>> Again, this stuff is already easy within Turbine and there is no need to
>> have it implement that interface.
>
> Jon, I believe that Marcelo really has a point here. PoolBrokerService
> should be inteface based, so that different implementations of pooling
> can be used. I'm sure that some people would be happy to use db
> connection
> pooling that is implemented in their middleware. This could be easily
> acomplished by defining a class wrapping around
> javax.sql.PooledConnection
> (or some such) that implemented TurbinePooledConnection interface (which
> would in turn extended java.sql.Connection).
>
> This is not a priority for me so I don't plan working on implementing it
> in forseeable future, but still I think it's a neat idea.
>
> Rafal
Rafal, please read what he wrote. He wants us to make DBConnection implement
java.sql.Connection. There is no need for that.
-jon
--
Honk if you love peace and quiet.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
