1 Reply Latest reply on Aug 12, 2004 8:53 PM by adrian.brock

Disabling CachedConnectionManager

ironbeard Aug 12, 2004 8:25 PM

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:

http://www.jboss.org/index.html?module=bb&op=viewtopic&t=49041
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=49044

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 Aug 12, 2004 8:53 PM (in response to ironbeard)

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
Actions