Wow, that's a far better suggestion than mine. Choice is king. Sorry I hadn't noticed that one. I'll see about helping out there.
I think the prefered pluggable interface there would be javax.sql.DataSource. Jonathan Fedor Karpelevitch wrote: >It has been already pointed out that the rigth thing to do would be to >refactor connection pooling to allow pluggable implementations of it. You >would then be able to plug in any implementation you like with pretty much >any license by writing minimal amount of interface code. The reason this has >not been done yet (as I understand) is only that nobody did it. Your >contribution would be very welcome. > >fedor. > >------------------------------- >"That's one small step for man, one giant leap for mankind." - Jesus Christ, >the sea of Tiberias > >>-----Original Message----- >>From: Jonathan Carlson [mailto:[EMAIL PROTECTED]] >>Sent: Thursday, October 18, 2001 2:35 PM >>To: [EMAIL PROTECTED] >>Subject: DB connection pooling >> >> >>Somehow I feel I might get flamed on this, but I have to say it. One >>thing to consider: PoolMan (http://poolman.sf.net) may handle these >>issues better or differently than the current Turbine connection >>pooling. It is licensed under the LGPL so it could be >>distributed with >>Turbine and then the Turbine developers could spend more time on >>developing functionality that would set Turbine apart even >>more than it >>already is instead of reinventing the wheel. >> >>Please don't flame me. I understand that some Apache types >>don't like >>anything GNU and that there is probably some good reasons to >>stick with >>the existing Turbine pooling mechanism. I'm also not familiar at all >>with the quality of the PoolMan code, so my suggestion may >>not be worth >>anything. >> >>If the only downside was the licensing difference, I'd go with not >>recreating the wheel. >> >>For what it's worth, >> >>Jonathan Carlson >>[EMAIL PROTECTED] >> >>[EMAIL PROTECTED] wrote: >> >>>>The pool will get new connections on an as needed basis up to some >>>>maximum amount. Since you need some connections available >>>> >>outside the >> >>>>pool, you would set the number used by the pool to a fraction >>>>of those available from the db. The pool does not have a dynamic >>>>resizing of the maximum number of connections. >>>> >>>I see. Another thing that confuses me is that I observe some strange >>>behavior: in the log file it shows something like >>> >>>(in + out = total): 4 + 8 = 12 >>> >>>Database connections are used by the application only for >>>short periods of time and then released back to the pool and records >>>like that appear in the log file when I know for sure that none of >>>the connections should be in use. And if I list open >>> >>connections using my >> >>>db server utilities, it shows only 4 open connections for my >>> >>application >> >>>which is consistent with what log file shows for available >>> >>connections. >> >>>It looks like ConnectionPool.totalConnections contains wrong >>> >>information >> >>>(it's supposed to be 4 as well) which is not good because >>>ConnectionPool.getConnection() won't establish any new connections if >>>totalConnections >= maxConnections. Could you please clarify >>> >>what might be >> >>>going on? >>> >>>Thanks and best regards, >>>Alexander Vorobiev >>> >>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>For additional commands, e-mail: [EMAIL PROTECTED] >>> >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >
