YAPoolMan 1.0 Beta1 released

YAPoolMan(From http://sourceforge.net/projects/yapoolman\) is the complete re-write of PoolMan and have more improvements. It inherits major PoolMan features such as

* A centralized xml configuration file

* JDBC driver and data source

* JMX support

However, this project - YAPoolMan, differs quite a lot on the following aspects:

* I believe statement and resultset caching is not necessary, or, for me, I think it is harmful. Since a cached statement should only be used during one check out/check in cycle, most programmer will reuse their statement object anyway, and if you want same statement cached among different users, most modern RDBMS do it quite well. Resultset caching is just a disaster, I never turn it on. The only times I mistakenly turned it on only wasted my time to scratch my head for the mystery broken update code. Besides, caching the result should be better implemented at application level, which means, developer should cache the data object they are interested, rather than the raw material - the resultset. So in YAPoolMan, only connections are pooled.

* Separation of pool and factory. Pool no longer creates objects, factory takes the responsibility.

* Support multiple servers. For example, there is a database server having two connecting nodes in the cluster, you can have the factory creating connections connecting to either node. Weight of the server can be used to balance the load. Servers can also be grouped into different priority, marked as busy standby or fail standby.

* Use dynamic proxy to replace the current connection handler implementation. This way, it not required to modify the code if JDBC standard keeps changing. This has some disadvantages, for example, it will affect performance. A direct method call is faster than call through a dynamic proxy. Since only connection and statement is proxied, I think the impact is acceptable.

* Proxy Handler to provide aspect like control over the pooled object. It can be used to change the behavior before the proxy invocation, after the invocation and when exception occurs.

* Configuration file is processed using Jakarta Commons-Digester, and reflects the separation of pool and factory.

Other changes are

* A simplified JNDI implementation is provided.

* Refactor the packages into pool, factory, jndi, config, jdbc and jmx.

* Only one check thread to replace life guard and skimmer threads.

* Follow java naming convention to use upper case correctly. For example, getJndiName instead of getJNDIName, initialPoolSql instead of initialPoolSQL, etc.

* Element name of xml configuration file is same as corresponding property name

* Jakarta Commons-Logger is used to replace log4j.

* Log category, instead of log file name should be configured in xml configuration file

* Other class name, interface name, method name and field name refactoring

* Full javadoc for public, protected and default elements.

* Object pool can also be bind to JNDI service. Rather than the jdbc pool, which binds the data source object, object pool will register the pool itself.

* When return object/connection to pool, you can indicate whether it is status is OK or bad. Pool will destroy it immediately if status is not OK.

* And other minor changes can be found in JavaDoc