1
|
#
|
2
|
# The CDM-Server instantiates the 3cp0 connection pools on behalf of the cdm-remote-webapp
|
3
|
# instances and passes the the connection pool per JNDI to the cdm-webapp instances. Thus
|
4
|
# we need to repeat the configuration as defined in
|
5
|
# cdmlib-persistence\src\main\resources\c3p0-config.xml
|
6
|
#
|
7
|
# For some applications, high performance is more important than the risk of an
|
8
|
# occasional database exception. In its default configuration, c3p0 does no
|
9
|
# Connection testing at all. Setting a fairly long idleConnectionTestPeriod, and
|
10
|
# not testing on checkout and check-in at all is an excellent, high-performance
|
11
|
# approach. (from official doc)
|
12
|
#
|
13
|
|
14
|
## idleConnectionTestPeriod:
|
15
|
# if this is a number greater than 0, c3p0
|
16
|
# will test all idle, pooled but unchecked-out connections, every this
|
17
|
# number of seconds.
|
18
|
# If database restarts will be rare so quick recovery is not an issue,
|
19
|
# consider reducing the frequency of tests by idleConnectionTestPeriod
|
20
|
# to, say, 300, and see whether clients are troubled by stale or broken
|
21
|
# Connections. If not, stick with 300, or try an even bigger number.
|
22
|
#
|
23
|
c3p0.idleConnectionTestPeriod = 600
|
24
|
|
25
|
c3p0.testConnectionOnCheckout = false
|
26
|
c3p0.testConnectionOnCheckin = false
|
27
|
|
28
|
c3p0.minPoolSize = 1
|
29
|
####### timeout parameters
|
30
|
#
|
31
|
# Some general advice about all of these timeout parameters: Slow down! The point
|
32
|
# of Connection pooling is to bear the cost of acquiring a Connection only once,
|
33
|
# and then to reuse the Connection many, many times. Most databases support Connections
|
34
|
# that remain open for hours at a time. There's no need to churn through all your
|
35
|
# Connections every few seconds or minutes. Setting maxConnectionAge or maxIdleTime
|
36
|
# to 1800 (30 minutes) is quite aggressive. For most databases, several hours may
|
37
|
# be more appropriate. You can ensure the reliability of your Connections by testing
|
38
|
# them, rather than by tossing them. (see Configuring Connection Testing.) The only
|
39
|
# one of these parameters that should generally be set to a few minutes or less is
|
40
|
# maxIdleTimeExcessConnections. (from official doc)
|
41
|
|
42
|
## maxConnectionAge
|
43
|
# Seconds, effectively a time to live. A Connection older than
|
44
|
# maxConnectionAge will be destroyed and purged from the pool.
|
45
|
#
|
46
|
# turned off as suggested above
|
47
|
#c3p0.maxConnectionAge = 600
|
48
|
|
49
|
# maxIdleTime 10800 = 3 hours
|
50
|
c3p0.maxIdleTime = 10800
|
51
|
|
52
|
c3p0.maxIdleTimeExcessConnections = 300
|
53
|
|
54
|
## automatichoweverTestTable:
|
55
|
# If provided, c3p0 will create an
|
56
|
# empty table of the specified name, and use queries against that table
|
57
|
# to test the Connection. If automaticTestTable is provided, c3p0 will
|
58
|
# generate its own test query, therefore any preferredTestQuery set
|
59
|
# will be ignored. You should not work with the named table after c3p0
|
60
|
# creates it; it should be strictly for c3p0's use in testing your
|
61
|
# Connection.
|
62
|
c3p0.automaticTestTable = _c3p0ConnectionTest
|
63
|
|
64
|
# if you do not want c3p0 to register MBeans with your JMX environment, you can suppress JMX support entirely
|
65
|
# The ManagementCoordinator was causing problems in the past but seem to be ok now.
|
66
|
#c3p0.management.ManagementCoordinator=com.mchange.v2.c3p0.management.NullManagementCoordinator
|