1 2 3 Previous Next 33 Replies Latest reply on Oct 20, 2011 6:00 AM by Tom Jenkinson Go to original post
      • 15. Re: Remote Txn Inflow: Synchronizations
        Jonathan Halliday Master

        It's hard to do lazily when all the communication is top down - there is no mechanism for the child to call up to the parent to register. You'd have to piggyback the registration on the return leg of a top down call rather than initiating a new bottom up one for it.  That's roughly one of the reasons I'm preferring to build the remoting transport around the jta rather than the jts. For example, the replay completion recovery model in jts won't work with remoting either - it needs the top down xa recovery scan model instead.

        • 16. Re: Remote Txn Inflow: Synchronizations
          David Lloyd Master

          Tom Jenkinson wrote:

           

          David Lloyd wrote:

           

          Yeah that should be fine, just let me know what the method hooks will be.  I'm also fine with using SubordinationManager directly, or providing an alternative extended version of com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple, or whatever is easiest for you guys.  In particular, at a protocol level it does us no good to have all the execptions mapped to XAException because we'll just have to decode it again and send it over the wire; it just costs an extra, useless transaction wrapping.

           

          I don't think we should expose SubordinationManager directly as we don't necessarily want to make that a public API. As such we should probably expose a new API specific to the job, I have posted this on the other thread so people watching that thread only will get the update.

           

          Well, that API is already public so I think that ship has sailed.  That said I'd hate to pile more work on you guys in the name of Yet Another Abstraction (gods know we have enough of those already).

           

          Here's the deal with public API support.

           

          On the client side, our jboss-ejb-client JAR is expected to be forwards compatible from now until pretty much the end of time.  That means, no using non-standard transaction APIs, period - the "outflow" of the transaction is done purely via the TransactionManager and TransactionSynchronizationRegistry implementations and via XAResource, and I don't see this changing anytime soon.  The client cannot do anything that cannot be done with these interfaces.

           

          The server side (which needs to consume this API) is a completely different matter.  The wire protocol is our point of compatibility; everything else is tightly coupled to the AS release.  The classes which inflow the transaction into the server can be as proprietary and/or expedient as we need them to be - and given the late hour, it's not the time for any grand new abstraction layers.  We already have tight coupling with JBossTS - allowing pluggable transaction managers in AS 7 isn't something I see happening (and if it does, that would be the time to revisit abstraction layers).

           

          So what I'm saying is, I'd hate to see you guys dragged into a lot of unnecessary work when 95% of the required API already exists.

          • 17. Re: Remote Txn Inflow: Synchronizations
            David Lloyd Master

            Tom Jenkinson wrote:

             

            Hi David,

             

            If you are happy do wait for JTA interposed Synchronization behavior, but do eventually want the same, may I ask you to raise a Jira for it? You can assign it to me if you like and mark it is a dependency of: https://issues.jboss.org/browse/JBTM-895. If you want, you can mark it as a fix for 4.15.x

             

            Tom

            I opened https://issues.jboss.org/browse/JBTM-909 for this work.

            • 18. Re: Remote Txn Inflow: Synchronizations
              Tom Jenkinson Master

              Jonathan Halliday wrote:

               

              It's hard to do lazily when all the communication is top down - there is no mechanism for the child to call up to the parent to register.

              This is what I was thinking also. Without having some way to expose the transaction managers as network endpoints (and the work within ArjunaJTA to make it possible to talk to them), as Jonathan says I think we are at the mercy of top-down approach and the workarounds that approach needs.

              • 19. Re: Remote Txn Inflow: Synchronizations
                Tom Jenkinson Master

                David Lloyd wrote:

                 

                Tom Jenkinson wrote:

                 

                I don't think we should expose SubordinationManager directly as we don't necessarily want to make that a public API. As such we should probably expose a new API specific to the job, I have posted this on the other thread so people watching that thread only will get the update.

                 

                Well, that API is already public so I think that ship has sailed.  That said I'd hate to pile more work on you guys in the name of Yet Another Abstraction (gods know we have enough of those already).

                 

                Sorry, I must not have the code in my workspace that uses SubordinationManager outside of jbosstm? Can you point me at the code that uses it directly then I can take a look to see? I have JCA, AS and jbosstm branch in a workspace and grepped it for text string "SubordinationManager" but the only references I found where in jbosstm.

                 

                The abstraction I am proposing is not going to be heavy, and it will probably be useful so that we know what was added for this work and can potentially vary SubordinationManager independent of this API. I was just going to put it in the atsintegration module. I would expect your proxy endpoints to do things like:

                 

                JTADistributionManager.getDistributionManager().commit(XID)

                 

                Or whatever, this would call code I would provide that looks a bit like this:

                 

                public void commit (Xid xid) throws XAException

                            SubordinateTransaction tx = SubordinationManager.getTransactionImporter().getImportedTransaction(xid).commit();

                 

                That said, if you can point me at code "in the wild" that uses SubordinationManager directly (as I say, it could be a module I don't have checked out) I am happy to review the proposed solution and use SubordinationManager as a public API and extend that accordingly. For instance though, access to this API in JCA is mediated through the XATerminatorImple.

                • 21. Re: Remote Txn Inflow: Synchronizations
                  David Lloyd Master

                  Tom Jenkinson wrote:

                   

                  David Lloyd wrote:

                   

                  Tom Jenkinson wrote:

                   

                  I don't think we should expose SubordinationManager directly as we don't necessarily want to make that a public API. As such we should probably expose a new API specific to the job, I have posted this on the other thread so people watching that thread only will get the update.

                   

                  Well, that API is already public so I think that ship has sailed.  That said I'd hate to pile more work on you guys in the name of Yet Another Abstraction (gods know we have enough of those already).

                   

                  Sorry, I must not have the code in my workspace that uses SubordinationManager outside of jbosstm? Can you point me at the code that uses it directly then I can take a look to see? I have JCA, AS and jbosstm branch in a workspace and grepped it for text string "SubordinationManager" but the only references I found where in jbosstm.

                  Yes, but it's public in that module. Whether or not an API is public is determined by wether it's public, not by whether it's being used in a particular codebase.

                   

                   

                  Tom Jenkinson wrote:

                   

                  The abstraction I am proposing is not going to be heavy, and it will probably be useful so that we know what was added for this work and can potentially vary SubordinationManager independent of this API. I was just going to put it in the atsintegration module. I would expect your proxy endpoints to do things like:

                   

                  JTADistributionManager.getDistributionManager().commit(XID)

                   

                  Or whatever, this would call code I would provide that looks a bit like this:

                   

                  public void commit (Xid xid) throws XAException

                              SubordinateTransaction tx = SubordinationManager.getTransactionImporter().getImportedTransaction(xid).commit();

                   

                  That said, if you can point me at code "in the wild" that uses SubordinationManager directly (as I say, it could be a module I don't have checked out) I am happy to review the proposed solution and use SubordinationManager as a public API and extend that accordingly. For instance though, access to this API in JCA is mediated through the XATerminatorImple.

                  There's just no reason to decouple this code, unless you really want to do the extra work.  From our perspective, if we used SubordinationManager directly, and then you made some incompatible change, we'd simply change our usage of it accordingly for the version of AS that included the updated TS; it's really not necessary to create an abstraction for our benefit.  The best API is not the one with the most abstractions, but the fewest - less code for everyone to maintain, and simpler contracts, mean a win for everyone in most cases.  (I could go on about API design all day...)

                   

                  I just want to make it absolutely, perfectly clear that this is not a requirement as far as we're concerned, we consider it to be much more important to hit the EAP 6 target than to have an abstraction layer over code which is already public (in the concrete Java sense, not in the socio-political sense you are alluding to).  It is up to you to decide if it is worth it.

                  • 22. Re: Remote Txn Inflow: Synchronizations
                    Tom Jenkinson Master

                    David Lloyd wrote:

                     

                    Tom Jenkinson wrote:

                     

                    Sorry, I must not have the code in my workspace that uses SubordinationManager outside of jbosstm? Can you point me at the code that uses it directly then I can take a look to see? I have JCA, AS and jbosstm branch in a workspace and grepped it for text string "SubordinationManager" but the only references I found where in jbosstm.

                    Yes, but it's public in that module. Whether or not an API is public is determined by wether it's public, not by whether it's being used in a particular codebase.

                    OK, I think I understand where you are coming from now. I am more familiar with the following interpretation of a "public" API: one that may be coded against, vs. an internal API (which may have public methods). In this I am currently classing SubordinationManager as an internal API. I note the point about you being happy to code against whatever we provide so when I get into it I will see if it can be provided directly by SubordinationManager directly without adding inconsistencies to the established code.

                    • 23. Re: Remote Txn Inflow: Synchronizations
                      David Lloyd Master

                      Tom Jenkinson wrote:

                       

                      Jonathan Halliday wrote:

                       

                      It's hard to do lazily when all the communication is top down - there is no mechanism for the child to call up to the parent to register.

                      This is what I was thinking also. Without having some way to expose the transaction managers as network endpoints (and the work within ArjunaJTA to make it possible to talk to them), as Jonathan says I think we are at the mercy of top-down approach and the workarounds that approach needs.

                      We'd need to probably come up with some clever way to modify recovery processing, I can't think of any other way to solve this.

                       

                      Are we sure that we need afterCompletion synchronization processing to be executed in terms of the root controller?  The only time I can imagine it mattering is if it is controlling some resource that is outside of the JVM, outside of the transaction, and yet visible to other participants.  If synchronizations are used for the purpose of discovering the overall outcome of the transaction, then executing on the local node achieves that purpose.  Same thing if the purpose is to clean up some per-VM resource.  And I think these two use cases are by far the predominant ones.

                       

                      I would argue that it is actually more effective to define the behavior in terms of the single VM.  Especially considering that no other solution seems to be forthcoming...

                       

                      For our purposes, it might be best to come out and specify that afterCompletion only runs in terms of the individual VM's view of the overall transaction.  Then later on we can revisit having this behavior be configurable, if we actually find a good solution for how to perform this recovery.

                       

                      I know it's probably not an ideal solution, but I think it will cover 95% of the use cases correctly, and I suspect that the last 5% ought to be using proper XAResources of their own.

                      • 24. Re: Remote Txn Inflow: Synchronizations
                        Tom Jenkinson Master

                        David Lloyd wrote:

                         

                        Tom Jenkinson wrote:

                         

                        Jonathan Halliday wrote:

                         

                        It's hard to do lazily when all the communication is top down - there is no mechanism for the child to call up to the parent to register.

                        This is what I was thinking also. Without having some way to expose the transaction managers as network endpoints (and the work within ArjunaJTA to make it possible to talk to them), as Jonathan says I think we are at the mercy of top-down approach and the workarounds that approach needs.

                        We'd need to probably come up with some clever way to modify recovery processing, I can't think of any other way to solve this.

                         

                        Are we sure that we need afterCompletion synchronization processing to be executed in terms of the root controller?  The only time I can imagine it mattering is if it is controlling some resource that is outside of the JVM, outside of the transaction, and yet visible to other participants.  If synchronizations are used for the purpose of discovering the overall outcome of the transaction, then executing on the local node achieves that purpose.  Same thing if the purpose is to clean up some per-VM resource.  And I think these two use cases are by far the predominant ones.

                         

                        I would argue that it is actually more effective to define the behavior in terms of the single VM.  Especially considering that no other solution seems to be forthcoming...

                         

                        For our purposes, it might be best to come out and specify that afterCompletion only runs in terms of the individual VM's view of the overall transaction.  Then later on we can revisit having this behavior be configurable, if we actually find a good solution for how to perform this recovery.

                         

                        I know it's probably not an ideal solution, but I think it will cover 95% of the use cases correctly, and I suspect that the last 5% ought to be using proper XAResources of their own.

                        From reading your message, I have understood your requirement to be the following:

                         

                        Cascade beforeCompletion to subordinate TMs

                        Cascade prepare

                        Cascade commit/rollback (triggering afterCompletions locally)

                         

                        i.e. do not factor out afterCompletions to a separate cascade. In that case, it is possible to get afterCompletions firing in the scenario where the transaction fails to complete correctly (i.e some XAR made a heuristic descision).

                        • 25. Re: Remote Txn Inflow: Synchronizations
                          David Lloyd Master

                          Tom Jenkinson wrote:

                           

                          David Lloyd wrote:

                           

                          Tom Jenkinson wrote:

                           

                          Jonathan Halliday wrote:

                           

                          It's hard to do lazily when all the communication is top down - there is no mechanism for the child to call up to the parent to register.

                          This is what I was thinking also. Without having some way to expose the transaction managers as network endpoints (and the work within ArjunaJTA to make it possible to talk to them), as Jonathan says I think we are at the mercy of top-down approach and the workarounds that approach needs.

                          We'd need to probably come up with some clever way to modify recovery processing, I can't think of any other way to solve this.

                           

                          Are we sure that we need afterCompletion synchronization processing to be executed in terms of the root controller?  The only time I can imagine it mattering is if it is controlling some resource that is outside of the JVM, outside of the transaction, and yet visible to other participants.  If synchronizations are used for the purpose of discovering the overall outcome of the transaction, then executing on the local node achieves that purpose.  Same thing if the purpose is to clean up some per-VM resource.  And I think these two use cases are by far the predominant ones.

                           

                          I would argue that it is actually more effective to define the behavior in terms of the single VM.  Especially considering that no other solution seems to be forthcoming...

                           

                          For our purposes, it might be best to come out and specify that afterCompletion only runs in terms of the individual VM's view of the overall transaction.  Then later on we can revisit having this behavior be configurable, if we actually find a good solution for how to perform this recovery.

                           

                          I know it's probably not an ideal solution, but I think it will cover 95% of the use cases correctly, and I suspect that the last 5% ought to be using proper XAResources of their own.

                          From reading your message, I have understood your requirement to be the following:

                           

                          Cascade beforeCompletion to subordinate TMs

                          Cascade prepare

                          Cascade commit/rollback (triggering afterCompletions locally)

                           

                          i.e. do not factor out afterCompletions to a separate cascade. In that case, it is possible to get afterCompletions firing in the scenario where the transaction fails to complete correctly (i.e some XAR made a heuristic descision).

                          That is correct.  However I argue that because of the non-durability of afterCompletions, this is no worse than the existing situation - anyone who relies on afterCompletion for the correctness of their transaction is subject to data loss if the VM crashes after the transaction is committed but before afteCompletion runs.  Because of this, as far as I see it, the only correct usage of afterCompletion is cleaning up local resources that don't survive a VM crash.  I just doesn't seem like a big loss to me.

                          • 26. Re: Remote Txn Inflow: Synchronizations
                            Tom Jenkinson Master

                            As we are somewhat free to implement this behavior free of spec constraints (as it isn't in a spec) we are free to make these kind of descisions. I worry though that by not attempting to perform afterCompletion after the transaction has been commit/rollback we are introducing an inconsistency with JTS that will be confusing to a user who is familiar with JTS?

                             

                            For now I will proceed down the line of calling aftercompletion as part of commit/rollback as you requested, if we decide that this needs its own phase after further consultation with the community (Jonathan/Mark?) we can factor it into a separate cycle.

                            • 27. Re: Remote Txn Inflow: Synchronizations
                              Mark Little Master

                              Yes piggybacking works too: we do that with interposition in JTS.

                              Jonathan Halliday wrote:

                               

                              It's hard to do lazily when all the communication is top down - there is no mechanism for the child to call up to the parent to register. You'd have to piggyback the registration on the return leg of a top down call rather than initiating a new bottom up one for it.  That's roughly one of the reasons I'm preferring to build the remoting transport around the jta rather than the jts. For example, the replay completion recovery model in jts won't work with remoting either - it needs the top down xa recovery scan model instead.

                              • 28. Re: Remote Txn Inflow: Synchronizations
                                Mark Little Master

                                It is worth noting that afterCompletion is a best effort invocation too. Of course you're supposed to try to call them for all registered synchronizations, but if they aren't delivered (or are ignored), they'll have no impact on the transaction outcome anyway. Synchronizations are required to be implemented to cope with afterCompletion not being delivered anyway.

                                David Lloyd wrote:

                                 

                                Are we sure that we need afterCompletion synchronization processing to be executed in terms of the root controller?  The only time I can imagine it mattering is if it is controlling some resource that is outside of the JVM, outside of the transaction, and yet visible to other participants.  If synchronizations are used for the purpose of discovering the overall outcome of the transaction, then executing on the local node achieves that purpose.  Same thing if the purpose is to clean up some per-VM resource.  And I think these two use cases are by far the predominant ones.

                                 

                                • 29. Re: Remote Txn Inflow: Synchronizations
                                  Mark Little Master

                                  No inconsistency. They're best effort.

                                  Tom Jenkinson wrote:

                                   

                                  As we are somewhat free to implement this behavior free of spec constraints (as it isn't in a spec) we are free to make these kind of descisions. I worry though that by not attempting to perform afterCompletion after the transaction has been commit/rollback we are introducing an inconsistency with JTS that will be confusing to a user who is familiar with JTS?

                                   

                                  For now I will proceed down the line of calling aftercompletion as part of commit/rollback as you requested, if we decide that this needs its own phase after further consultation with the community (Jonathan/Mark?) we can factor it into a separate cycle.