Thread: [c3p0-users] c3p0-0.9.2-pre1 (New Version)
Status: Beta
Brought to you by:
swaldman
From: Steve W. <swa...@mc...> - 2010-05-27 06:15:26
|
It has been an unforgivable, embarrassingly long time of dormancy, but c3p0 is under active development again. c3p0-0.9.2-pre1 has been posted on SourceForge. As always, I appreciate people beating it up and letting me know all the things that I've screwed up. c3p0 development can now be followed via Mercurial repositories on SourceForge. Note that there are two repositories, c3p0 itself and a library upon which it depends, mchange-commons. There are still a lot of pent-up issues to be resolved for c3p0-0.9.2. This version will be about fixing what's broken or not so great; the next version will add support for JDBC 4 api. My apologies to all JDBC users for the shitty maintenance/support over the last couple of years. smiles, Steve Release notes & Changelog: > RELEASE NOTES, c3p0-0.9.2-pre1 > ============================== > > Some highlights: > > + Some JDBC drivers freeze up if cached Statements are close()ed > while their parent > Connections are in use. Previously users of these drivers (Oracle, > JTDS) generally > had to forego Statement caching to avoid deadlocks. C3P0's > statement cache can now > be set to cautiously close Statements only when the parent > Connections are known > to be idle. If you experience "APPARENT DEADLOCKS" due to > StatementCloseTasks, set > > c3p0.statementCacheNumDeferredCloseThreads=1 > > and they should go away! > > + There are some other minor improvements and fixes: > > -- the more granual and efficient "scattered" Connection > acquisition algorithm that > was "experimental" in the previous release is enabled by > default > > -- unreturned Connections that are timed out (bad! bad!) are > either rolled back (default) > or committed before close(), respecting your unresolved > transaction configuration. > (see config parameter unresolvedConnectionTimeout in docs). > > + You must now include two jar files (c3p0 and mchange-commons) in > your CLASSPATH > rather than just one. Both can be found in the lib directory of > the binary distribution. > (Please provide feedback; if this is very inconvenient I can > bundle it all up into > a unified jar.) > > Some structural changes: > > + Source distributions will no longer be distributed on sourceforge > as jar or zip files. > Please use Mercurial [ http://mercurial.selenic.com/ ] to download > the latest source > code. Once you have installed Mercurial, downloading source should > be as easy as... > > hg clone http://c3p0.hg.sourceforge.net:8000/hgroot/c3p0/mchange-commons > hg clone http://c3p0.hg.sourceforge.net:8000/hgroot/c3p0/c3p0 > > Note that c3p0 depends (heavily) on the mchange-commons library. > > I apologize very, very much for disappearing for a couple of years. > > As always, please give the library a very thorough beating. Your > testing and feedback > are very much appreciated, to Steve Waldman <swa...@mc...>, > please. --- > c3p0-0.9.2-pre1 > -- Implemented asynchronous Statement destroyer, hopefully > completing the task of > making the statement cache robust to drivers that cannot > deal with Statements > being closed underneath Connections still in use (e.g. > Oracle, JTDS). Note > that this implementation requires at least one dedicated > Thread for statement > destruction (if we used the common Thread pool, there > will be deadlocks as > Statement close tasks await not-in-use Connections, while > Connection-related > tasks can't be completed because the Thread pool is > saturated with Statement > close tasks. Stats about the asynchronous Statement > destroyer are available > via the JMX MBean, prefixed statementDestroyer. Setting > the new config parameter > c3p0.statementCacheNumDeferredCloseThreads enables the fix. > -- Resolved a potential race condition that could lead to > pool freezes, especially > when acquisitions occasionally fail and acquireIncrement > is set to 1. [Many > thanks to Brendan Dougherty for carefully describing this > issue.] > -- Added a guard to BasicResourcePool.doAcquire() to ensure > that the pool has > not been closed or broken before assimilating a task > [Many thanks to > Sean Rohead for tracking down this issue and suggesting > the fix.] > -- Made SCATTERED_ACQUIRE_TASK default to true. This > provides much better overall > performance for Connection acquisition from potentially > unreliable sources > -- Modifed to ensure that unresolved transaction settings > apply to expired > unreturned Connections. (see config params > autoCommitOnClose and > forceIgnoreUnresolvedTransactions) [Thanks to Matthew > Lieder for calling > attention to this issue.] > -- Cleaned up Statement cache fix that ensures no statements > are closed while > their parent Connection is in use. By default, the fix is > not enabled, because > it's extra work that most databases don't need. [Most > drivers support Statement > close() while a parent Connection is in use, so the extra > work is unnecessary.] > -- Separated traditional build into two libraries, mchange- > commons and c3p0. > -- Modified GooGooStatementCache and > C3P0PooledConnectionPool to ensure that > 1) the Statement cache knows which Connections are > currently in use by outside > clients; and 2) the Statement cache refuses to cull > Statements belonging to > Connections in use. Theoretically, drivers should support > asynchronous statement > close. In practice, some drivers don't do so nicely, or > block pending completion > of other (potentially long) operations, leading to > APPARENT DEADLOCKS. (Oracle > users in particular have reported deadlocks in which all > pool threads are blocked > on Statement close tasks.) [Many, many thanks to Ovidiu > Feodorov for a very detailed > account of problems that occur under c3p0 when very long > queries are executed under > Oracle!] > -- Defined a NullMLogger, and modified Log4jMLog to use > that, instead of a broken > log4j MLogger, if c3p0's logging library fails to acquire > a non-null Log4j logger. > Thanks to Oli Glimmer for calling attention to this > issue. (Strange NPEs due to > apparently null log4j loggers have been encountered > before, and previous attempts > to resolve apparently weren't adequate.) > -- Fixed a problem whereby ThreadPoolAsynchronousRunner was > not robust to Errors provoked > during task execution. [Thanks to George Khoshy for > reporting this issue.] > -- Made VersionUtils more robust to cases where some > components of the java.version system > property are non-integral [Thanks to Dirk Weigenand for > calling attention to this problem, > and suggesting a solution!] > |