Many Connections to one ManagedConnection

[andrew_m]

Jboss version : 3.0.1_tomcat4.0.4

We have created a resource adapter which connects to a network node which implements its own security protocol. Each client of this system has an id which we have wrapped up and pass as the criteria to getConnection(). We have Jboss configured to allocation connections based on our criteria i.e. ByApplication. One of our requirements is that all calls to getConnection() with the same criteria result in obtaining a connection associated to the same ManagedConnection i.e. potentially one-to-many.

I have tried several different ways to get this to work, but it seems from examining the code that the default behaviour is to create a new ManagedConnection instance if there is already a Connection handle associated with the one we want. This arises because JBoss separates out the ManagedConnection pool based on the configuration (ByApplication in our case) and once one is checked out that is it - it won't attempt to match it again until cleanup() has been called after the associated connection handle has been closed. (This happens in more than one thread)

I understand from previous postings from David that the reason for matchManagedConnection only being called with one (already matched effectively) ManagedConnection is to improve concurrency, but I can't see a "safe" way to have a many to one relationship. The only thing we have got to work is to modify the behaviour of createManagedConnection to return a matching one if it already exists. This is obviously incorrect as it is the behaviour that I would expect from matchManagedConnection instead. Am I missing somthing or is there something we can configure differently?

Sorry for the very wordy post but I wanted to make clear that I understand the implications of open connection handles etc. I have tried to summarize below.

Current behaviour
Bean 1 calls getConnection()
Correct ManagedConnection is returned
Bean 2 calls getConnection with same criteria
New ManagedConnection created
Both call close
cleanup() called on both ManagedConnections

Desired behaviour
Bean 1 calls getConnection()
Correct ManagedConnection is returned
Bean 2 calls getConnection with same criteria
Same ManagedConnection created
Bean 1 calls close()
Nothing happens
Bean 2 calls close()
cleanup() called on ManagedConnection

Regards,
Andrew

[davidjencks]

You didn't specify the level of tx support you are using. This is relevant. I assume that each thread is in a different or no transaction, since the jca1.5 spec basically prohibits more than one thread doing work on a transaction concurrently.

In any case, I don't see how having any number, possibly infinite, of ManagedConnections from the pool supplied to matchManagedConnections will help you, since you want one that isn't in the pool.

The behaviour you want is similar to the "tie cx to tx" behavior needed for local transaction support, except you want it tied to the security info instead. I think your choices are:

1. change the requirements

2. implement your own ConnectionManager with a security-based cache similar to the tx-based cache in LocalTxCOnnectionManager

3. modify your adapter so ManagedConnections are not so tightly tied to physical connections, but choose a physical connection based on the security info. Depending on your backend this might enable you to provide tx support.

[andrew_m]

As far as transactions are concerned we are not using them.

As for your suggestions:

1. change the requirements

I wish we could always do this to solve hard problems!

2. implement your own ConnectionManager with a security-based cache similar to the tx-based cache in LocalTxCOnnectionManager

I'm not sure what the security information has to do with this. We are not propagating security information as such. The Subject is always set to null. The only difference between requests to createManagedConnection() is the ConnectionRequestInfo which contains an id which the adapter maps to some security info. Whether this is security information or not is irrelevant - it's just some matching criteria. Unfortunately this also isn't an option as we will have to integrate with other app servers as well.

3. modify your adapter so ManagedConnections are not so tightly tied to physical connections, but choose a physical connection based on the security info. Depending on your backend this might enable you to provide tx support.

This may be a possibility. I was under the impression from reading the JCA spec (1.0) that a ManagedConnection was supposed to represent a physical connection and I had interpreted this to mean one-to-one. I expected the many-to-one relationship to be between Connections and ManagedConnections. However, I guess we could move this releationship down without impacting anything above us, and maintaining postability between app servers.

[davidjencks]

> As far as transactions are concerned we are not using
> them.
>
> As for your suggestions:
>
> 1. change the requirements
>
> I wish we could always do this to solve hard
> problems!

It's still your best bet with this problem. Maybe there's a different way to look at the problem...
>
> 2. implement your own ConnectionManager with a
> security-based cache similar to the tx-based cache in
> LocalTxCOnnectionManager
>
> I'm not sure what the security information has to do
> with this. We are not propagating security
> information as such. The Subject is always set to
> null. The only difference between requests to
> createManagedConnection() is the
> ConnectionRequestInfo which contains an id which the
> adapter maps to some security info. Whether this is
> security information or not is irrelevant - it's just
> some matching criteria. Unfortunately this also isn't
> an option as we will have to integrate with other app
> servers as well.

I'm calling it security info, but you are correct that match gets arbitrary info from the Subject and ConnectionRequestInfo objects. If I understand your situation correctly, the basic problem remains that you are trying to get the connection manager to give you a handle to a physical connection that is in use, and not in the pool. It seems to me that if you wish to continue to tie the managed connection 1-1 to the physical connection (as suggested by the jca docs, I agree) you will have to write your own connection manager: the tx to cx link in the LocalTxConnectionManager (or TxConnectionManager in 3.2 and 4) is an example of a solution to a similar situation. If you can loosen the tie between physical and ManagedConnections you may be able to use a "standard" connection manager.
>
> 3. modify your adapter so ManagedConnections are
> not so tightly tied to physical connections, but
> choose a physical connection based on the security
> info. Depending on your backend this might enable you
> to provide tx support.
>
> This may be a possibility. I was under the impression
> from reading the JCA spec (1.0) that a
> ManagedConnection was supposed to represent a
> physical connection and I had interpreted this to
> mean one-to-one. I expected the many-to-one
> relationship to be between Connections and
> ManagedConnections. However, I guess we could move
> this releationship down without impacting anything
> above us, and maintaining postability between app
> servers.

The jca spec does indeed want you to tie physical and managed connections 1-1. It's pretty easy to write an adapter that doesn't do this that works on jboss (or other server that creates only a single copy of the ManagedConnectionFactory) but there are problems that I haven't solved writing an adapter like this that works on weblogic (which serializes everything all the time and appears to create new ManagedConnectionFactories based on their properties whenever you get the ConnectionFactory from jndi). Adapters like this may be easier to write with the jca 1.5 spec, where there is a single ResourceAdapter object with more or less defined lifetime that you can use to hold maps and canonical ManagedConnectionFactory instances. I'm trying to solve this problem for the firebird database adapter.