transaction support in JBossAS 5.0

[jhalliday]

I'm doing some work on integrating JBoss Transactions JTA with the 5.0 beta of JBossAS. For the most part it's going fairly well, but I'm having some issues with the new DTM (tx over jboss remoting) in 5.0.

As far as I can tell, the DTM is written with the assumption that it's working with the JBoss appserver tx manager. This assumption breaks when the tx manager is swapped for the JBoss Transaction JTA implementation.

I'm seeing a ClassCastException in the DTMServant.create method:

TransactionImpl tx = (TransactionImpl)tm.suspend();

Since the JBossTS TransactionImple has a different API, I need to make some changes in this method. Our integration code already has support for the TxPropagationContext. However, our Xid code does not have the notion of a localId.

I'm looking into ways to generate a uniq long value from our Xids as a substitute. My initial impression is that this will be difficult - the Xid state space is simply larger than the long state space, so no 1:1 mapping is possible.

Anyhow, if anyone has any thoughts on the best way to tackle the integration issue I'd be interested. If we can't find a relatively straightforward integration approach, we may have to drop the DTM from the 5.0 branch until we can resolve this.

Regards

Jonathan Halliday
JBoss Transactions Team

[marklittle]

We're now close to fully integrating JBossTS into JBAS 5.0. There have been some discussions in the past around the roadmap (http://labs.jboss.com/portal/jbosstm/resources/integrationroadmap.html). The old TM and DTM code are being removed and replaced with JBossTS, but community support for the old TM work can continue. Unfortunately there are some issues with retaining the current DTM that uses JBoss Remoting which is in the current source branch, so we will have to remove it for now. Hopefully you can update it eventually to work with JBossTS (http://jira.jboss.com/jira/browse/JBTM-14).

[starksm64]

Dropping the remoting based dtm until it can be revisited is the desired approach.

[marklittle]

Yes, I got confirmation from Andy M. on that earlier today as well. Thanks.

[reverbel]

Two different subjects were mentioned here:

(1) the best way of integrating the remoting-based DTM, which currently works only with the old TM, with JBossTS, and

(2) the removal of the TM/DTM code from the current source branch.

I suggested Jonathan to take the technical discussion of subject (1) to this forum, but am not sure this is the right place for discussing subject (2)... Anyway, given the decision of dropping the remoting-based DTM from JBAS 5.0, subject (2) appears to be the most urgent one.

Mark mentioned that community work on the JBoss TM can continue. Will JBoss still support such work by keeping the TM in a JBoss-hosted source repository (even if not in the JBAS 5.0 branch) and by letting the TM sources be updated by the community?

I ask the question above because a research project of mine relies on the TM code and is likely to produce updates on that code. (One of my M.Sc. students is finishing the implementation of a "WS-AT shell" over the TM code, which now fully supports logging and crash recovery.) This is academic work that may not fit into a professional open-source vision, so I am certainly not demanding JBoss/RH support to such a project. Should I fork the TM and take this project elsewhere? Or perhaps jboss.org would have interest in hosting it as a "community labs project"?

Regards,

Francisco

[reverbel]

"jhalliday" wrote:

Our integration code already has support for the TxPropagationContext. However, our Xid code does not have the notion of a localId.

I'm looking into ways to generate a uniq long value from our Xids as a substitute. My initial impression is that this will be difficult - the Xid state space is simply larger than the long state space, so no 1:1 mapping is possible.

Anyhow, if anyone has any thoughts on the best way to tackle the integration issue I'd be interested.

The best solution would be to keep (localId,Xid) associations in a hash map. This would give you the advantages of localIds and would require no changes to the DTM code. Alternatively, you could change the DTM to make it use full Xids where it currently uses localIds. Technically this would be worse, as the usage of "small" localIds avoids bloating of remote references (CORBA IORs and JBossRemoting URIs) to OTS/DTM objects such as Coordinator and Resource. Instead of embedding a full Xid into, say, the object id part of an IOR, the OTS/DTM code uses a long (the local transaction id) as the CORBA object id. Besides reducing wire traffic and marshalling overhead, this approach reduces logging overhead, as it reduces the size of transaction log records that contain Resource or Coordinator references.

The TM code uses this solution (a hash map) to associate localIds to foreign transactions. (It does not need the hash map in the case of a locally-started transaction, as a TM-generated Xid includes a localId, which can be extracted from the Xid.)

Note that a distributed transaction does not need to have the same localId across VMs. Each VM touched by a transaction creates its own localId for that transaction. Most likely those localIds won't be all equal. In a given JBoss server, however, a transaction must always be assigned the same localId -- even across server restarts. So localIds *must* be saved in the transaction log.

The fact that the integration effort must reach the JBossTS log may appear to be a disadvantage of what I am suggesting... Note, however, that this would happen anyway (even if you replace localIds by full Xids!), as JBossRemoting-specific URIs referencing remote Resources must be saved in the Coordinator's log. Similarly, each remote Resource must save the Coordinator URI in its log. (BTW: localIds make those log records much smaller!)

Regards,

Francisco

[marklittle]

"reverbel" wrote:
Two different subjects were mentioned here:

(1) the best way of integrating the remoting-based DTM, which currently works only with the old TM, with JBossTS, and

(2) the removal of the TM/DTM code from the current source branch.

I suggested Jonathan to take the technical discussion of subject (1) to this forum, but am not sure this is the right place for discussing subject (2)... Anyway, given the decision of dropping the remoting-based DTM from JBAS 5.0, subject (2) appears to be the most urgent one.

Yes, (2) is the priority because of AS 5.0.

Mark mentioned that community work on the JBoss TM can continue. Will JBoss still support such work by keeping the TM in a JBoss-hosted source repository (even if not in the JBAS 5.0 branch) and by letting the TM sources be updated by the community?

I ask the question above because a research project of mine relies on the TM code and is likely to produce updates on that code. (One of my M.Sc. students is finishing the implementation of a "WS-AT shell" over the TM code, which now fully supports logging and crash recovery.) This is academic work that may not fit into a professional open-source vision, so I am certainly not demanding JBoss/RH support to such a project. Should I fork the TM and take this project elsewhere? Or perhaps jboss.org would have interest in hosting it as a "community labs project"?

That's a good question. There have been a lot of changes to the AS codebase recently to accomodate JBossTS. Those changes may affect what your student has done, so he may need to recode some stuff. However, I don't see why it shouldn't be possible to host this old code within labs as we originally thought. Let me check and get back to you.

[marklittle]

"reverbel" wrote:

"jhalliday" wrote:

Our integration code already has support for the TxPropagationContext. However, our Xid code does not have the notion of a localId.

I'm looking into ways to generate a uniq long value from our Xids as a substitute. My initial impression is that this will be difficult - the Xid state space is simply larger than the long state space, so no 1:1 mapping is possible.

Anyhow, if anyone has any thoughts on the best way to tackle the integration issue I'd be interested.

The best solution would be to keep (localId,Xid) associations in a hash map. This would give you the advantages of localIds and would require no changes to the DTM code. Alternatively, you could change the DTM to make it use full Xids where it currently uses localIds. Technically this would be worse, as the usage of "small" localIds avoids bloating of remote references (CORBA IORs and JBossRemoting URIs) to OTS/DTM objects such as Coordinator and Resource. Instead of embedding a full Xid into, say, the object id part of an IOR, the OTS/DTM code uses a long (the local transaction id) as the CORBA object id. Besides reducing wire traffic and marshalling overhead, this approach reduces logging overhead, as it reduces the size of transaction log records that contain Resource or Coordinator references.

I will just say that the problems with storing anything that isn't guaranteed to be globally unique are fairly obvious and risky where transaction processing is concerned.

The TM code uses this solution (a hash map) to associate localIds to foreign transactions. (It does not need the hash map in the case of a locally-started transaction, as a TM-generated Xid includes a localId, which can be extracted from the Xid.)

Note that a distributed transaction does not need to have the same localId across VMs. Each VM touched by a transaction creates its own localId for that transaction. Most likely those localIds won't be all equal. In a given JBoss server, however, a transaction must always be assigned the same localId -- even across server restarts. So localIds *must* be saved in the transaction log.

The fact that the integration effort must reach the JBossTS log may appear to be a disadvantage of what I am suggesting... Note, however, that this would happen anyway (even if you replace localIds by full Xids!), as JBossRemoting-specific URIs referencing remote Resources must be saved in the Coordinator's log. Similarly, each remote Resource must save the Coordinator URI in its log. (BTW: localIds make those log records much smaller!)

Regards,

Francisco

If we get round to doing the JBossRemoting + JBossTS task then we should definitely look at the capabilities within JBossTS that could be leveraged to our advantage.

[reverbel]

However, I don't see why it shouldn't be possible to host this old code within labs as we originally thought.

That would be great.

Let me check and get back to you.

Thanks! Regards,

Francisco

[reverbel]

"reverbel" wrote:

Instead of embedding a full Xid into, say, the object id part of an IOR, the OTS/DTM code uses a long (the local transaction id) as the CORBA object id. Besides reducing wire traffic and marshalling overhead, this approach reduces logging overhead, as it reduces the size of transaction log records that contain Resource or Coordinator references.

I will just say that the problems with storing anything that isn't guaranteed to be globally unique are fairly obvious and risky where transaction processing is concerned.

Not sure what was your point here... Resource and Coordinator references are globally unique, as each such reference contains endpoint info such as host and port, plus a local id field that is unique within that endpoint. Usage of "really local" ids (rather than using full Xids as local id values) avoids nesting of globally unique identifiers, which would be a wasteful thing to do.

Regards,

Francisco

[kconner]

There have been a lot of changes to the AS codebase recently to accomodate JBossTS. Those changes may affect what your student has done, so he may need to recode some stuff.

I would be very surprised if that was the case. The changes to AS have been to generalise accesses to the org.jboss.tm classes, removing any specific dependencies on the current implementation.

[marklittle]

There have been a lot of changes to the AS codebase recently to accomodate JBossTS. Those changes may affect what your student has done, so he may need to recode some stuff.

I would be very surprised if that was the case. The changes to AS have been to generalise accesses to the org.jboss.tm classes, removing any specific dependencies on the current implementation.

Maybe, but he won't know until he tries. This was a word of warning. Hence the use of the word 'may'.

[marklittle]

"reverbel" wrote:

"reverbel" wrote:

Instead of embedding a full Xid into, say, the object id part of an IOR, the OTS/DTM code uses a long (the local transaction id) as the CORBA object id. Besides reducing wire traffic and marshalling overhead, this approach reduces logging overhead, as it reduces the size of transaction log records that contain Resource or Coordinator references.

I will just say that the problems with storing anything that isn't guaranteed to be globally unique are fairly obvious and risky where transaction processing is concerned.

Not sure what was your point here... Resource and Coordinator references are globally unique, as each such reference contains endpoint info such as host and port, plus a local id field that is unique within that endpoint. Usage of "really local" ids (rather than using full Xids as local id values) avoids nesting of globally unique identifiers, which would be a wasteful thing to do.

Regards,

Francisco

But if these longs or integers are being stored with the log as a reference to a Resource/Coordinator/Xid, then eventually your identifier will wrap. This means that it's possible for the same id to be used to key into different Resource/Coordinator/Xids at the same time.

[kconner]

Maybe, but he won't know until he tries. This was a word of warning. Hence the use of the word 'may'.

All three of the areas which were modified for TS contain localised changes which replace direct calls to TxManager with the appropriate interface. No changes were exposed and the defined functionality remains the same.

It may be that there are modifications in other areas that will have an impact but they should see no difference wrt the changes which were necessary for TS.

[reverbel]

"reverbel" wrote:

"reverbel" wrote:

Instead of embedding a full Xid into, say, the object id part of an IOR, the OTS/DTM code uses a long (the local transaction id) as the CORBA object id. Besides reducing wire traffic and marshalling overhead, this approach reduces logging overhead, as it reduces the size of transaction log records that contain Resource or Coordinator references.

I will just say that the problems with storing anything that isn't guaranteed to be globally unique are fairly obvious and risky where transaction processing is concerned.

Not sure what was your point here... Resource and Coordinator references are globally unique, as each such reference contains endpoint info such as host and port, plus a local id field that is unique within that endpoint. Usage of "really local" ids (rather than using full Xids as local id values) avoids nesting of globally unique identifiers, which would be a wasteful thing to do.

Regards,

Francisco

But if these longs or integers are being stored with the log as a reference to a Resource/Coordinator/Xid, then eventually your identifier will wrap. This means that it's possible for the same id to be used to key into different Resource/Coordinator/Xids at the same time.

In practical terms, this is not possible if local transaction ids are 64-bit longs. Even with a sustained transaction rate of one million TPS (one transaction per microsecond!), it would take more than five hundred thousand years (!!) for a 64-bit transaction counter to wrap:

60 seconds/min * 60 mins/hr * 24 hrs/day * 365 days/year = 31536000 seconds/year

2^64 transactions/wrap * 10^-6 seconds/transaction * 31536000 seconds/year = 584942.41 years/wrap

Regards,

Francisco