[jboss-dev-forums] [Design of JBoss Transaction Services] - Re: transaction support in JBossAS 5.0

[mark.little@jboss.com]

"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.

anonymous wrote : 
  | 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.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976800#3976800

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976800