org.shiftone.ooc.factory
Class PooledDataSourceObjectFactory

java.lang.Object
  org.shiftone.ooc.factory.BaseObjectFactory
      org.shiftone.ooc.factory.PooledDataSourceObjectFactory

All Implemented Interfaces:

javax.naming.spi.ObjectFactory

public class PooledDataSourceObjectFactory

extends BaseObjectFactory

This ObjectFactory uses the c3p0 connection pooling implementation to pool JDBC connections. To use this factory, the c3p0 library (jar) MUST be in the classpath. c3p0 is NOT part of the OOC distribution.

http://sourceforge.net/projects/c3p0

The following options may be passed to c3p0 via refAddrs. All options must include the prefix "c3p0." in order for them to be passed to c3p0. The following list of options is directly quoted from the com.mchange.v2.c3p0.PoolConfig

Property Name	Built-In Default	Comments
c3p0.initialPoolSize	3
c3p0.minPoolSize	3
c3p0.maxPoolSize	15
c3p0.idleConnectionTestPeriod	0	If this is a number greater than 0, c3p0 will test all idle, pooled but unchecked-out connections, every this number of seconds.
c3p0.maxIdleTime	0	Seconds a Connection can remain pooled but unused before being discarded. Zero means idle connections never expire.
c3p0.maxStatements	0	The size of c3p0's PreparedStatement cache. Zero means statement cahing is turned off.
c3p0.propertyCycle	300	Maximum time in seconds before user configuration constraints are enforced. c3p0 enforces configuration constraints continually, and ignores this parameter. It is included for JDBC 3 completeness.
c3p0.acquireIncrement	3	Determines how many connections at a time c3p0 will try to acquire when the pool is exhausted.
c3p0.testConnectionOnCheckout	false	Don't use. Very expensive. If true, an operation will be performed at every connection checkout to verify that the connection is valid. Better choice: verify connections periodically using c3p0.idleConnectionTestPeriod
c3p0.autoCommitOnClose	false	The JDBC spec is unforgivably silent on what should happen to unresolved, pending transactions on Connection close. C3P0's default policy is to rollback any uncommitted, pending work. (I think this is absolutely, undeniably the right policy, but there is no consensus among JDBC driver vendors.) Setting autoCommitOnClose to true causes uncommitted pending work to be committed, rather than rolled back on Connection close. [Note: Since the spec is absurdly unclear on this question, application authors who wish to avoid bugs and inconsistent behavior should ensure that all transactions are explicitly either committed or rolled-back before close is called.]
c3p0.forceIgnoreUnresolvedTransactions	false	Strongly disrecommended. Setting this to true may lead to subtle and bizarre bugs. This is a terrible setting, leave it alone unless absolutely necessary. It is here to workaround broken databases / JDBC drivers that do not properly support transactions, but that allow Connections' autoCommit flags to go to false regardless. If you are using a database that supports transactions "partially" (this is oxymoronic, as the whole point of transactions is to perform operations reliably and completely, but nonetheless such databases are out there), if you feel comfortable ignoring the fact that Connections with autoCommit == false may be in the middle of transactions and may hold locks and other resources, you may turn off c3p0's wise default behavior, which is to protect itself, as well as the usability and consistency of the database, by either rolling back (default) or committing (see c3p0.autoCommitOnClose above) unresolved transactions. This should only be set to true when you are sure you are using a database that allows Connections' autoCommit flag to go to false, but offers no other meaningful support of transactions. Otherwise setting this to true is just a bad idea.
c3p0.connectionTesterClassName	com.mchange. v2.c3p0.impl. DefaultConnectionTester	See ConnectionTester
c3p0.numHelperThreads	3	c3p0 is very asynchronous. Slow JDBC operations are generally performed by helper threads that don't hold contended locks. Spreading these operations over multiple threads can significantly improve performance by allowing multiple operations to be performed simultaneously.
c3p0.factoryClassLocation	null	DataSources that will be bound by JNDI and use that API's Referenceable interface to store themselves may specify a URL from which the class capable of dereferencing a them may be loaded. If (as is usually the case) the c3p0 libraries will be locally available to the JNDI service, leave this set as null.

Version:

$Revision: 1.4 $

Author:

Jeff Drost

Field Summary

static java.lang.String

PARAM_DATA_SOURCE

Constructor Summary

PooledDataSourceObjectFactory()

Method Summary

java.lang.Object

getObjectInstance(java.util.Properties properties, javax.naming.Reference reference, javax.naming.Name name, javax.naming.Context nameCtx, java.util.Hashtable environment)

Methods inherited from class org.shiftone.ooc.factory.BaseObjectFactory

getObjectInstance, getObjectInstance

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Detail

PARAM_DATA_SOURCE

public static final java.lang.String PARAM_DATA_SOURCE

See Also:

Constant Field Values

Constructor Detail

PooledDataSourceObjectFactory

public PooledDataSourceObjectFactory()

Method Detail

getObjectInstance

public java.lang.Object getObjectInstance(java.util.Properties properties,
                                          javax.naming.Reference reference,
                                          javax.naming.Name name,
                                          javax.naming.Context nameCtx,
                                          java.util.Hashtable environment)
                                   throws java.lang.Exception

Overrides:

getObjectInstance in class BaseObjectFactory

Throws:

java.lang.Exception