1 Reply Latest reply on Aug 12, 2004 8:53 PM by Adrian Brock

    Disabling CachedConnectionManager

    ironbeard Newbie

      Although I'm not using OJB, I am using JDO and I was having problems similar
      to those mentioned in these (and lots of other) posts:


      I followed the suggested work-around in 49041 and disabled the
      CachedConnectionInterceptor. That fixed the problem. And it makes
      sense -- since the CachedConnectionManager was generating the errors,
      not invoking it would tend to stop them.

      From the JBoss docs:

      The CachedConnectionManager mbean manages associations between meta-aware
      objects (those accessed through interceptor chains) and connection handles,
      and between user transactions and connection handles. Normally there should
      only be one such mbean. It is called by CachedConnectionInterceptor,
      UserTransaction, and all BaseConnectionManager2 instances.

      It sure looks like the managed connection pool is still being properly
      maintained, even without invoking the CCM. So is it completely optional?
      Just a performance improvement? What are the ramifications of dropping it
      from the interceptor chain?

        • 1. Re: Disabling CachedConnectionManager
          Adrian Brock Master

          The CCM (Cached ConnectionManager) is optional.

          A well written app (by which I mean one that doesn't use all the bad patterns
          provided by the spec) doesn't need the CachedConnectionInterceptor.

          Its main use for well written apps, is to catch unclosed connections
          during development.

          If you start doing non-scalable stuff like unshared connections then
          you do need it.

          The other reason for the CachedConnectionInterceptor is lazy
          transaction enlistment e.g.

          Connection c = dataSource.getConnection();

          UserTransaction ut = // do lookup;
          ut.begin(); // the CCM enlists the connection in the transaction