[Design of JBoss Transaction Services] - Re: transaction support in JBossAS 5.0
by 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
19 years, 6 months
[Design of JBoss Transaction Services] - Re: transaction support in JBossAS 5.0
by mark.little＠jboss.com
"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.
anonymous wrote :
| 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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976799#3976799
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976799
19 years, 6 months
[Design of JBoss Transaction Services] - Re: transaction support in JBossAS 5.0
by 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
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976778#3976778
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976778
19 years, 6 months
[Design of JBoss Transaction Services] - Re: transaction support in JBossAS 5.0
by 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
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976765#3976765
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976765
19 years, 6 months
[Design of POJO Server] - Re: Allowing multiple AbstractParsingDeployer to work with t
by alex.loubyansky＠jboss.com
"scott.stark(a)jboss.org" wrote : The jbossxb methods taking a SchemaResolver used by SchemaResolverDeployer do not take an existing root(although I don't know why they could not).
The reason was that the way to merge two (or more) XML contents into one Java object model wasn't obvious (w/o requiring a user to write the merging code). Of course, we could define some rules to support this.
For an example of a non-obvious merging issue, imagine we have ejb-jar.xml and jboss.xml listing a set of beans. How can I get the ejb-jar bean info for a jboss bean info being parsed? We can't rely on the same ordering of bean infos in ejb-jar and jboss.xml (they can be different and some beans maybe missing from jboss.xml or bean infos from ejb-jar could be collected into a java.util.Set and iteration order would be different). This can only be done by ejb-name. In this case, the user would have to provide some merging logic (writting custom element handlers, probably).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976761#3976761
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976761
19 years, 6 months