the issue I am not following is for DataSource and other JCA deployments that rely on a CRI, Subject etc. I would assume that for recovery purposes, a default connection of some sort will have to be provided by the client to allow JBossTS to do it's job. This would seem to suggest that we are now at the very least going to force a separate deployment for recovery if the default deployment cannot be accessed in this manner. The JMS example assumes the creation of a connection without JMS credentials so I am assuming I am in the same boat.

I can't see any other way to do this unless we made them provide a separate configuration file for their resources that we could access that would allow me to recreate the underlying resource.

I believe that the configuration file approach is the *easiest* way to accomplish this. Assuming that a client specifies all the relevant information in a file where I can recreate the underlying connection and then the XAResource this would seem to be pretty straightforward.

The DSName of course is not going to mean a f*@#$*! thing and I don't even know why I brought it up. No way to really obtain the XAResource from there anyway...sheer stupidity on my part.

the issue I am not following is for DataSource and other JCA deployments that rely on a CRI, Subject etc. I would assume that for recovery purposes, a default connection of some sort will have to be provided by the client to allow JBossTS to do it's job. This would seem to suggest that we are now at the very least going to force a separate deployment for recovery if the default deployment cannot be accessed in this manner. The JMS example assumes the creation of a connection without JMS credentials so I am assuming I am in the same boat.

I can't see any other way to do this unless we made them provide a separate configuration file for their resources that we could access that would allow me to recreate the underlying resource.

When I wrote the ResourceRecovery instance for the JMS bridge, it gets its config from a properties file, which also (optionally) contains the username and password to create the XAConnection to get the XASession and XAResource.

Also, one thing I noticed when doing the XA recovery work for JBM is that the JMSProviderXAResourceRecovery instance that was done for JBossMQ is broken.

The way JBoss TS recovery manager works is as follows:

It calls:

myXAResourceRecovery.hasMoreResources()

returns true

myXAResourceRecovery.getXAResource()

returns resource

myXAResourceRecovery.hasMoreResources()

returns false

it then calls recover() as appropriate on the XAResoource

and then commit/rollback as appropriate

and then, and it *throws the XAResource away*

then on the next time around (120 seconds later or whatever)

it goes through the whole procedure again.

The way the JBossMQ XAResourceRecovery was written is that it never returns true to hasMoreResources after the first time.

So any in doubt transactions after that time will never be picked up.

Also the concept of an XAResourceWrapper which will transparent reconnect doesn't make much sense to me, if you bear in mind the above. Since JBoss TS will throw away the Wrapper anyway after the pass.

You may as well create a new one on each pass. (This is what we do) It certainly makes the code a lot simpler.

For JCA resources this is not straightforward being that the underlying connection (and thus access to the XAResource) cannot always be easily recreated.

In the recovery work for JBM, you simply pass the name of the JMSProviderAdapter to your RecoveryModule implementation which allows you to access the XAConnection->XASession->XAResource.

In many cases in JCA deployments this isn't that straightforward for a variety of reasons:

1) The underlying resource requires an authenticated Subject to be created

2) The underlying resource requires programmatic user information (ConnectionRequestInfo) that is not supplied in the deployment.

3) Unlike JMS, most JCA deployments do not provide XA based connection factories for client use. In other words you cannot simply get a reference to the connection factory in JNDI and get the XAResource.

What you need is a repository of XA TxConnectionManagers and MDBactivations (these are setup by the deployments).

When JBossTS asks you to recover, you iterate over this repository and retrieveall the XAResources.

All you need is a mechanism to get a link to this repository from your JBossTSplugin. If JBossTS supported proper IOC configuration this would trivial,instead you going to have to do some work.

Don't make the same mistake and introduce property files for your configuration!

The only configuration required is the security like you said.We discussed this nearly two years. It is trivially solved by allowinga connection factory or datasource to have two extra parameters to overridethe default user or when it doesn't have a default user.

You might also need a flag to say recovery cannot use (share) a normal pooled connection since I know at least in the past some XAResources had problems with normal operations after recover() is invoked.

Lovely. I actually won a bet. I bet someone at JBoss that you wouldn't post a response without saying something like this. Of course, given your nature I probably should have given him odds.

When JBossTS asks you to recover, you iterate over this repository and retrieveall the XAResources.

Ok, let's take a simple scenario:

JDBC based deployment using a security domain with a login config of CallerIdentityLoginModule. Just because the TxManager is deployed, doesn't mean the XAResource gets created. This comes off the underlying Connection which is only created when the pool is first used. So, what goes in the repository in this case? What do I iterate over during recovery?

How about a JDBC deployment that only support application-managed security? What if this is required information and can only be done via getConnection(username,password)?

We discussed this nearly two years.

Well, unless you think my name is something other than Weston (which you actually seem completely incapable of remembering) we haven't. I have been here one year, and let me tell you I have loved every day!

The example you posted as a sample security configuration basically just offloads what would be in the external config file to the *-ds.xml, fine. I am not sure why you are listing a local-tx-datasource as these won't be supporting recovery, but no matter. So, I am assuming that your

<recovery-security-domain>Recovery</recovery-security-domain>

is defined in login-config, so we have yet another piece of external information to 'kludge' this together it just happens to be in a 'comfortable' place that you are familiar with.

The aim is to try to make it zero configuration for recovery not asking them to configurethings in 5 different places.

I can understand supporting a seperate recovery plugin for standalone useof JBoss Messaging but NOT in the appserver please, it should beintegrated via JCA!

For the app server we intend to use the JMSProvider based XAResourceRecovery, although it has the drawback of not being able to specify username and password as already mentioned on this thread.

The custom one, which uses it's own properties file is only currently used for the messaging bridge, which doesn't use JCA. Although I am coming around to the idea of deploying JCA with it too (the standalone bridge is really just a stripped down JBoss AS) then we can use the standard XAResource receovery.

We would like to have a "full" recovery solution for JBM before JBM 1.2 (at the end of the month) , which would need to include specifying a username and password. I don't know if the new JCA stuff is going to ready in time for that, so we may have no choice than to use our own properties file or maybe we can change the datasource to take recovery username/password params as you mention.

JDBC based deployment using a security domain with a login config of CallerIdentityLoginModule. Just because the TxManager is deployed, doesn't mean the XAResource gets created. This comes off the underlying Connection which is only created when the pool is first used. So, what goes in the repository in this case? What do I iterate over during recovery?

How about a JDBC deployment that only support application-managed security? What if this is required information and can only be done viagetConnection(username,password)?

The cases we are talking about is where the security is already externally configured. There is no default user name or password or it is the wrong one.

It is either application-managed-security or security domain based.

In the case where there is no default and one is required, you need to configure it somewhere.

In the case where it is the wrong one (the normal runtime user doesn't have authority to invoke recover()) you also need a seperate configuration.

These are the 1% use cases for completeness. In 99% of uses cases the default user (either no user/password or the one form the security domain) will suffice for recovery to create the connection.

is defined in login-config, so we have yet another piece of external information to 'kludge' this together it just happens to be in a 'comfortable' place that you are familiar with.

No, it is the standard mechanism within the appserver for external security configuration.

Personally, I think JCA should have a SubjectFactory integration point which for the appserver uses JBoss-JAAS, but whatever you still need to name the factory to use and the security-domain config is as good an identifier as any.

e.g. In a standalone use case it could be a name for the SubjectFactory in the microcontainer.

We need to get into the JCA spec and define SPIs/APIs for recovery. What really sucks is that JBM is going to have to figure it out for every single app server out there if it wants to be usable in different environments. I guess people like ActiveMQ have already done the work though and we just need to steal the code...