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]

Reply via email to