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 Krzewski
Senior Internet Developer
mailto:[EMAIL PROTECTED]
+48 22 8534830 http://e-point.pl
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
