JBM2 jca adapter and connection factories

[ataylor]

This is how the JCA Adapter worked before clebert added the functionality to override the transport connector.

Each Resource Adapter defined in an ra.xml file creates a JBossConnectionFactory dependant on its configuration. Each MDB activation shares this connection factory and uses it to make its connections. with 1.4 this didn't matter i guess but in 2.0 its the connection factory (actually the underlying session factory) that takes care of such things as number of physical connections etc. This means that you could have many MDB's receiving messages over a small number of connections.

Clebert added a change to allow the transport connector to be over ridden, if it isn't things operate the same as above. If it is overridden then a new connection factory is created for the MDB activation. currently if this happens and the MDB activation is removed the connection factory isn't closed which is also incorrect however i'm guessing the garbage collection will do this.

If i add my change to allow the rest of the connection factory params to be over ridden then we would have to create a new connection factory every time any conf is overridden.

so do we

a) don't allow any overrides on the connection factory. The user would have to provide a new ra.xml file for each configuration. This is how 1.4 works and would mean removing cleberts changes, however would still be a problem with lots of MDB;s sharing a CF.

b) share the same connection factory unless any params are over ridden, in this case create a new one per MDB.

c) create a new Connection Factory per MDB activation.

or maybe have a configuration flag to allow the user to choose between b & c.

Note: this is for the inbound connector only

[timfox]

When you say create a new Cf per MDB, do you mean per MDB *instance* or per MDB type?

There may be many thousands of MDB instances (of the same type) in an AS.

[timfox]

Also.. how does it work with outbound?

[ataylor]

When you say create a new Cf per MDB, do you mean per MDB *instance* or per MDB type?

I mean per MDB activation, so per MDB deployed.

[timfox]

For inbound I think we should share the connection factory unless its overridden, in which case we create a new one for that MDB type.

The RA could maintain a "default" connection factory for use when nothing is overridden.

How does it work for outbound? Do we still use jms-ds.xml ??

[ataylor]

For inbound I think we should share the connection factory unless its overridden, in which case we create a new one for that MDB type.

The RA could maintain a "default" connection factory for use when nothing is overridden.

+1, for this i need to add some code to check to see if anything has been overridden and some code to make sure non default factories etc are torn down when the mdb is deactivated.

How does it work for outbound? Do we still use jms-ds.xml ??

yes we still use the jms-ds.xml. currently there is one connection factory per jms-ds.xml.

[timfox]

"ataylor" wrote:

yes we still use the jms-ds.xml. currently there is one connection factory per jms-ds.xml.

+1

[clebert.suconic]

a) don't allow any overrides on the connection factory. The user would have to provide a new ra.xml file for each configuration. This is how 1.4 works and would mean removing cleberts changes, however would still be a problem with lots of MDB;s sharing a CF.

Multiple ras for multiple connections are not acceptable IMO. With 1.4, you had a way to specify another CF JNDI.


You probably just need to have the CF at the ra level created lazily (I thought it already was).

You could have two Beans, or two jms-ds.xml deployed, one overridden, one at the ra level.

[ataylor]

You probably just need to have the CF at the ra level created lazily (I thought it already was).

yes it is, but that wasn't my point.

You could have two Beans, or two jms-ds.xml deployed, one overridden, one at the ra level.

not sure what you mean by this.

anyway, its sorted. b)