• We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      Reason:

      New connection checking cabapilities have been added:

      ------------------- forum snip -------------------------

      c3p0 does have quite extensive tools to permit you to ensure that Connections your application sees are not stale. By default, c3p0 does no Connection testing at all, because Connnection testing can be expensive. But c3p0 (as of v0.8.5-pre7 and above) provides the following parameters to permit as testing that is as cautious or as loose as you'd like:

      c3p0.automaticTestTable
      c3p0.preferredTestQuery
      c3p0.testConnectionOnCheckin
      c3p0.testConnectionOnCheckout [maps to hibernate.c3p0.validate]*
      c3p0.idleConnectionTestPeriod [maps to hibernate.c3p0.idle_test_period]*

      • NOTE that where hibernate maps c3p0 params to hibernate config params, hibernate users MUST use the hibernate versions, in your hibernate configuration, or your settings will be overridden by hibernate specified defaults! Other parameters should be specified in a file called c3p0.properties at the root of your application's effective CLASSPATH. [see http://forum.hibernate.org/viewtopic.php?t=934779&highlight= ]

      To reproduce the behavior you are seeing with Proxool – i.e. to have each Connection tested prior to checkout – set hibernate.c3p0.validate to true in your hibernate configuration.

      Testing every Connection on checkout is the most reliable, but also the most performance costly approach to Connection testing. If you do this with c3p0, I'd recommend you define c3p0.automaticTestTable or c3p0.preferredTestQuery, which may dramatically improve test performance. c3p0.automaticTestTable is the most convenient approach – just set this to the name of a table c3p0 can create and use to run test queries against.

      Another good approach to connection testing is to define c3p0.testConnectionOnCheckin and c3p0.idleConnectionTestPeriod. This is less reliable than testing in checkout, but has an advantage because check-in and idle tests are performed asynchronously by c3p0, and therefore less directly impact client performance. By setting both of these parameters, you can be assured that your Connection has been tested recently prior to a checkout, without putting the test synchronously in the client's code path. [In hibernate, do be sure to set hibernate.c3p0.idle_test_period in your hibernate config and c3p0.testConnectionOnCheckin separately in c3p0 properties file! See above!]

      ----------------------- snip --------------------------------

      This may resolve the problem of user's Confluence instances dropping out over night. A good description of the problem:

      ------------------------ snip -----------------------------

      What happens (can be reproduced every time) is:

      • A user signs in and does some work on the system.
        He gets a HTTP-session, a Hibernate session and a connection (on first DB-access)
      • The user signs out. Http-session is invalidated. Hibernate session is closed. (session.close)
      • DB-Connections are taken down. (DB-session timeout or DB-restart). DB comes back up.
      • Time passes. Long enough for all idle DB-connections in the C3P0 pool to time out.
      • A user signs on. A new Http-session is generated. A new Hibernate session is created.
      • The user tries to access the Database.
        The connection pool assigns THE OLD, BROKEN connection to the session, which fails consequently.

      ---------------------- snip ------------------------------------

              Unassigned Unassigned
              dave@atlassian.com dave (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved: