JBoss-3.0.0 does not match connections?

[polman]

Hi all,

I am trying to get my resource adapter for an
XML-database product to work under JBoss-3.0.0.
It worked ine under 2.4.4, and works under 3.0.0
except for the following problem: the method matchManagedConnections() is never called on my
ManagedConnectionFactory implementation (I checked
this by logging various calls to the resource adapter
classes).

matchManagedConnections() *was* called under 2.4.4,
causing the same managed connection to be used over
and over. Under 3.0.0, a new managed connection is
created each time.

In my ...-service.xml file, I tried every possibility
for the matching criteria line
(By...)
but nothing helps.

However, this I can imagine, since changing this
attribute probably only has effect when matchManagedConnections() *is* called.

Now, the logging information on the resource adapter reveals some more interesting things. Under 3.0.0
my managed connections are not cleaned up (which is
probably the reason they are not reused). Another
difference with 2.4.4 is that under 3.0.0 getLocalTransaction() is called *again* on a
managed connection right before committing. Why?
Could this be the reason why JBoss thinks the
managed connection cannot be cleaned up (and therefore not reused)?

thanks in advance

--MP--

[davidjencks]

In most if not all of the adapters I've written, at some time during development matchManagedConnections was never being called, and it was due to not notifying the ConnectionEventListeners when a connection handle was closed. Once I added the notification everything started working properly.

Other adapters do get matchManagedConnection called, so I am inclined to suspect a problem with your adapter.

[polman]

So was I, at first, but I couldn't find anything,
so I dowloaded the sources, added some logging messages,
and let it run. I tested both my own resource adapter
and cloudscape to compare. Cloudscape seemed to run
fine: the same connection is reused over and over,
which was the behavior I wanted for my resource adapter too. However, it seems that cloudscape works, but for the wrong reason. Three bits of JBoss code are important here:

From class: CachedConnectionManager
method: disconnect(Object key, Set unsharableResources)

---------------------
if (cmToConnectionsMap == null)
{
log.info("CCM: disconnect: returning");
return; //??? shouldn't happen
}
----------------------

From class: LocalTxConnectionManager
method: disconnect(Collection crs, Set unsharableResources)

----------------------
for (Iterator i = crs.iterator(); i.hasNext(); )
{
ConnectionRecord cr = (ConnectionRecord)i.next();
ManagedConnection mc = cr.mc;
cr.setManagedConnection(null);
unregisterAssociation(mc, cr.connection);
if (!mcs.contains(mc))
{
mcs.add(mc);
} // end of if ()
}
---------------------

From internal class: BaseConnectionEventListener
method: unregisterConnection(Object handle)

---------------------
handleCount--;
---------------------

Both tests are as follows: in a method of a stateful
sessionbean with transaction attribute "Required",
a connection to the resource is opened, some query is
performed, and the connection handle is closed (after which the transaction commits).

In the cloudscape test the message
"CCM: disconnect: returning" appears, which is odd,
since the comment says "shouldn't happen"

However, this seems to be a good thing, because
unregistering the association results in a proper
cleanup, so that the connection can be reused. In
my resource adapter test, the "else" part is executed
(cmToConnectionsMap is apparently not null),
resulting in the execution of the second piece
of code, resulting in execution of the third piece,
which finally causes the "handleCount" variable to
actually be set to a negative value.
A subsequent call to
-----------------
public boolean isManagedConnectionFree()
{
return handleCount == 0;
}
-----------------
will never return "true".

My question is: is the correct working of the cloudscape test a coincidence, or is my resource adapter (or its
...service.xml) incorrect?

If you want, I can send you both service files and
the relevant pieces of sample code.

Thanks in advance

--Mark Polman--

[davidjencks]

Anything you can send me would be great.
[e-mail]

I don't yet see how this can be happening...
thanks

[davidjencks]

The cloudscape version seems to work as I expect. I haven't tried the xhive version but still suspect it is not notifying connection close events.

I've changed the handle tracking code to be less redundant and not actually count handles but just keep track of them, and log when an attempt is made to remove a handle it doesn't know about. I also removed the misleading comments from the cached connection manager. Could you please try again with the cvs HEAD code and let me know what you find out?

thanks