Uploaded image for project: 'Commons Pool'
  1. Commons Pool
  2. POOL-108

GenericObjectPool does per-resource work (e.g. validate) in a synchronized context

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.3
    • Fix Version/s: 1.4
    • Labels:
      None

      Description

      While using the pool library with DBCP, and load testing with simulated failures, we noticed that a single bad connection can cause multiple threads to block when the test on borrow flag is true. (Using "select 1" as a test query.)

      Looking at the code, GenericObjectPool performs activation, passivation, and validate on both borrow and return, inside of synchronized methods. This can be a real problem, since any of these operations could conceivably block, in which case all threads trying to obtain or release a resource will also block for the duration. Some of these concerns are indirectly covered by POOL-93 in 2.0. Looking at revision 594226 I can see this has not yet been addressed.

      Narrowing the synchronization scope via synchronized blocks, rather than synchronizing the entire method, would deal with this easily enough. If I get the time I'll work up a patch. This should be addressed - in the context of DBCP it turns test on return / borrow into counter-intuitively dangerous options.

        Attachments

        1. GOP.patch
          6 kB
          Phil Steitz

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                matthew.moore Matthew Moore
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: