[jposee] r494 committed - Production C3P0 configuration contributed by Leonardo @ Cabal - THANK ...

81 views
Skip to first unread message

codesite...@google.com

unread,
Jun 11, 2013, 4:44:59 PM6/11/13
to jpos-c...@googlegroups.com
Revision: 494
Author: arevilla
Date: Tue Jun 11 13:44:42 2013
Log: Production C3P0 configuration contributed by Leonardo @ Cabal -
THANK YOU!

http://code.google.com/p/jposee/source/detail?r=494

Modified:
/trunk/opt/hibernate3/cfg/_hibernate.cfg.head

=======================================
--- /trunk/opt/hibernate3/cfg/_hibernate.cfg.head Thu Apr 7 17:09:01 2011
+++ /trunk/opt/hibernate3/cfg/_hibernate.cfg.head Tue Jun 11 13:44:42 2013
@@ -18,14 +18,57 @@

<property name="hibernate.c3p0.min_size">2</property>
<property name="hibernate.c3p0.max_size">20</property>
- <property name="hibernate.c3p0.timeout">300</property>
+ <!--maxIdleTime->Default: 0
+ Seconds a Connection can remain pooled but unused before being
discarded. Zero
+ means idle connections never expire. -->
+ <property name="hibernate.c3p0.timeout">120</property>
+ <!--
+ maxStatements -> Default: 0
+ The size of c3p0's global PreparedStatement cache. If both
maxStatements and
+ maxStatementsPerConnection are zero, statement caching will
not be enabled. If
+ maxStatements is zero but maxStatementsPerConnection is a
non-zero value,
+ statement caching will be enabled, but no global limit will be
enforced, only
+ the per-connection maximum. maxStatements controls the total
number of
+ Statements cached, for all Connections. If set, it should be a
fairly large
+ number, as each pooled Connection requires its own, distinct
flock of cached
+ statements. As a guide, consider how many distinct
PreparedStatements are used
+ frequently in your application, and multiply that number by
maxPoolSize to
+ arrive at an appropriate value. Though maxStatements is the
JDBC standard
+ parameter for controlling statement caching, users may find
c3p0's alternative
+ maxStatementsPerConnection more intuitive to use. -->
<property name="hibernate.c3p0.max_statements">300</property>
- <property name="hibernate.c3p0.idle_test_period">3000</property>
+ <!--idleConnectionTestPeriod -> Default: 0
+ if this is a number greater than 0, c3p0 will test all idle,
+ pooled but unchecked-out connections, every this number of
seconds. -->
+ <property name="hibernate.c3p0.idle_test_period">90</property>
+ <!-- unreturnedConnectionTimeout -> Default: 0 Seconds.
+ If set, if an application checks out but then fails to
check-in [i.e. close()]
+ a Connection within the specified period of time, the pool
will unceremoniously
+ destroy() the Connection. This permits applications with
occasional Connection
+ leaks to survive, rather than eventually exhausting the
Connection pool. And
+ that's a shame. Zero means no timeout, applications are
expected to close()
+ their own Connections. Obviously, if a non-zero value is set,
it should be to a
+ value longer than any Connection should reasonably be
checked-out. Otherwise,
+ the pool will occasionally kill Connections in active use,
which is bad. This
+ is basically a bad idea, but it's a commonly requested
feature. Fix your $%!@%
+ applications so they don't leak Connections! Use this
temporarily in
+ combination with debugUnreturnedConnectionStackTraces to
figure out where
+ Connections are being checked-out that don't make it back into
the pool! -->
+ <property
name="hibernate.c3p0.unreturnedConnectionTimeout">60</property>
+ <!-- debugUnreturnedConnectionStackTraces -> Default: false
+ If true, and if unreturnedConnectionTimeout is set to a
positive value, then
+ the pool will capture the stack trace (via an Exception) of
all Connection
+ checkouts, and the stack traces will be printed when
unreturned checked-out
+ Connections timeout. This is intended to debug applications
with Connection
+ leaks, that is applications that occasionally fail to return
Connections,
+ leading to pool growth, and eventually exhaustion (when the
pool hits
+ maxPoolSize with all Connections checked-out and lost). This
parameter should
+ only be set while debugging, as capturing the stack trace will
slow down every
+ Connection check-out. -->
+ <property
name="hibernate.c3p0.debugUnreturnedConnectionStackTraces">true</property>
<property
name="connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</property>
-
<property
name="hibernate.cache.use_structured_entries">true</property>
<property name="hibernate.cache.use_query_cache">true</property>
<property
name="hibernate.cache.use_second_level_cache">true</property>
<property
name="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</property>

-
Reply all
Reply to author
Forward
0 new messages