From the community documentation:
hibernate.hbm2ddl.auto Automatically validates or exports schema DDL to the database when the SessionFactory is created. With create-drop, the database schema will be dropped when the SessionFactory is closed explicitly.
e.g. validate | update | create | create-drop
So the list of possible options are,
- validate: validate the schema, makes no changes to the database.
- update: update the schema.
- create: creates the schema, destroying previous data.
- create-drop: drop the schema when the SessionFactory is closed explicitly, typically when the application is stopped.
- none: does nothing with the schema, makes no changes to the database
These options seem intended to be developers tools and not to facilitate any production level databases, you may want to have a look at the following question; Hibernate: hbm2ddl.auto=update in production?
DBCP is out of date and not production grade. Some time back we conducted an in-house analysis of the two, creating a test fixture which generated load and concurrency against the two to assess their suitability under real life conditions.
DBCP consistently generated exceptions into our test application and struggled to reach levels of performance which C3P0 was more than capable of handling without any exceptions.
C3P0 also robustly handled DB disconnects and transparent reconnects on resume whereas DBCP never recovered connections if the link was taken out from beneath it. Worse still DBCP was returning Connection objects to the application for which the underlying transport had broken.
Since then we have used C3P0 in 4 major heavy-load consumer web apps and have never looked back.
UPDATE: It turns out that after many years of sitting on a shelf, the Apache Commons folk have taken DBCP out of dormancy and it is now, once again, an actively developed project. Thus my original post may be out of date.
That being said, I haven't yet experienced this new upgraded library's performance, nor heard of it being de-facto in any recent app framework, yet.
Best Answer
This is a configuration I am using which keeps resources to a minimum. Of course you'll want to tailor your application to use the resources it needs...
Reference: http://www.mchange.com/projects/c3p0/index.html
testConnectionOnCheckin
validates the connection when it is returned to the pool.testConnectionOnCheckOut
, although would ensure active connections before use, would be too expensive to do.idleConnectionTestPeriod
sets a limit to how long a connection will stay idle before testing it. Without preferredTestQuery, the default isDatabaseMetaData.getTables()
- which is database agnostic, and although a relatively expensive call, is probably fine for a relatively small database. If you're paranoid about performance use a query specific to your database (i.e.preferredTestQuery="SELECT 1"
)maxIdleTimeExcessConnections
will bring back the connectionCount back down tominPoolSize
after a spike in activity.Below configuration sets poolsize between 3-20. Idle connections are retested every 5 minutes to keep them active. Because of
idleConnectionTestPeriod
, this will only keep the the minumum number of connections alive. If there are more than 3 connections at the 4-minute mark, it kills those connections freeing resources back to the minimum.Use of
maxIdleTimeExcessConnections
andidleConnectionTestPeriod
negates the need formaxIdleTime