1 2 3 4 5 Previous Next 74 Replies Latest reply on May 17, 2006 1:02 AM by mskonda Go to original post
      • 15. Re: XARecovery: Messaging integration with JBoss Transaction

        Not 100% sure, let me check..

        • 16. Re: XARecovery: Messaging integration with JBoss Transaction
          timfox

          Initially all we need to do is provide a mechanism by which JBoss Transactions can get hold of an XAResource so it can call recover().

          Previously we were just putting an instance of JMSRecoverable in JNDI so a transaction manager could pick it up and call recover() on it.

          I don't know which mechanism (if any) JBoss TS mandates for getting hold of XAResources so it can call recover() on them.

          Eventually we should look at using more out of JBoss TS e.g. object store but this is a much bigger task than the one at hand imo.

          For now we should just find out how to provide JBoss TS with the XAresource which hopefulyl should be quite simple.

          On making sure 2PC happens: Even if we enlist two resources in the tx then it's my understanding that even that's not sufficient to ensure 2PC since the TM may join the branchaes if it determines both resources are in the same resource manager, and then just use 1PC. That's what I observed with the old transaction manager anyway.

          • 17. Re: XARecovery: Messaging integration with JBoss Transaction

            As I mentioned in my first post, the MessagingResourceRecovery is the place holder for callign the relevant XAResource.

            The cycle works like this:

            1. The RecoveryManager gets hold of XAResoruce by calling getXAResource() method on MessagingResourceRecovery

            2. Once you get hold of XAResoruce, the recovery module can call the XAResource.recover

            The issue here is ResourceManager cannot invoke (according to Mark) the MessageResourceRecovery unless it finds any incomplete transactions in the object store (as it scans periodically).

            So, we should think of a hack!

            • 18. Re: XARecovery: Messaging integration with JBoss Transaction

              Mark

              Is there a way I can invoke MessagingResourceRecovery class irrespective of finding no transactions in the object store?

              The idea is - if RecoveryManager invokes this MessagingResourceRecovery, this class can provide the XAResource from which the RecoveryManager can call recover on it and problem solved!.

              • 19. Re: XARecovery: Messaging integration with JBoss Transaction
                timfox

                This doesn't make any sense to me.

                An XAResource provided by a third party system e.g. messaging, Oracle or whatever should be usuable by JBoss TS.

                After all, it would be silly to suggest Oracle rewrites it's XAResource implementation to use JBoss TS object store just so JBoss TS can use it, so why require that with JBoss Messaging.

                We should just be another XAResource from the POV of the transaction manager, how we are implemented is of no concern.

                • 20. Re: XARecovery: Messaging integration with JBoss Transaction
                  marklittle

                   

                  "timfox" wrote:
                  Initially all we need to do is provide a mechanism by which JBoss Transactions can get hold of an XAResource so it can call recover().

                  Previously we were just putting an instance of JMSRecoverable in JNDI so a transaction manager could pick it up and call recover() on it.

                  I don't know which mechanism (if any) JBoss TS mandates for getting hold of XAResources so it can call recover() on them.


                  The recovery manager picks up XAResource factories during recovery when/if it needs them. However, as I said in an earlier entry, you'd probably find it a lot easier if your XAResource implementations were serializable - then recovery is much more straightforward.


                  Eventually we should look at using more out of JBoss TS e.g. object store but this is a much bigger task than the one at hand imo.

                  For now we should just find out how to provide JBoss TS with the XAresource which hopefulyl should be quite simple.

                  On making sure 2PC happens: Even if we enlist two resources in the tx then it's my understanding that even that's not sufficient to ensure 2PC since the TM may join the branchaes if it determines both resources are in the same resource manager, and then just use 1PC. That's what I observed with the old transaction manager anyway.


                  They do need to be 2 different resource managers/unique participants to guarantee 2PC, but for testing purposes you can always disable the one-phase commit optimization. If you want to register multiple participants, then all you need do is make sure you have a dummy XAResource that doesn't rollback during prepare (it can return read-only though).

                  • 21. Re: XARecovery: Messaging integration with JBoss Transaction
                    marklittle

                     

                    "timfox" wrote:
                    This doesn't make any sense to me.

                    An XAResource provided by a third party system e.g. messaging, Oracle or whatever should be usuable by JBoss TS.

                    After all, it would be silly to suggest Oracle rewrites it's XAResource implementation to use JBoss TS object store just so JBoss TS can use it, so why require that with JBoss Messaging.

                    We should just be another XAResource from the POV of the transaction manager, how we are implemented is of no concern.


                    That's entirely correct. It doesn't matter where your XAResource stores its information (in the JBossTS object store is just one possibility, but it doesn't affect the correctness of the system). All you need do is ensure that the XAResource participates in the JBossTS transaction. If it's serializable then that's really all you have to do. If it's not serializable, then you need to implement a factory interface that the recovery manager picks up when it replays the log. But because we use presumed abort, we'll only write into the log after the prepare phase has completed and the transaction coordinator instance decides to commit.

                    If there's nothing in the log, then one of the following occurred:

                    (i) the XAResource instance wasn't registered with a JBossTS transaction; check that the transaction service was correctly installed within JBossAS.

                    (ii) the XAResource instance returned read-only during prepare, so it was dropped from the 2nd phase and no log entry was needed.

                    (iii) the XAResource instance returned abort during prepare, so the transaction rolled back.

                    (iv) the XAResource instance was the only participant in the transaction, so 1PC was used and in which case no log entry was created.

                    (v) there's a bug in JBossTS.

                    (vi) the transaction committed; the XAResource instance received prepare and commit, as did all participants in the transaction, and all log entries were removed.

                    Since we've run with XAResources from a variety of different sources (JDBC, JMS, Web Services) with JBossTS over the years, I'd rule out (v) - or at least put it down the bottom of the list for now.

                    Hopefully this helps.

                    • 22. Re: XARecovery: Messaging integration with JBoss Transaction
                      marklittle

                       

                      "mskonda" wrote:

                      The issue here is ResourceManager cannot invoke (according to Mark) the MessageResourceRecovery unless it finds any incomplete transactions in the object store (as it scans periodically).


                      It's more a "won't" than a "cannot". If there is no log entry, then there's nothing to recover. If the participant still exists, then it MUST rollback. It needs to call into the transaction service and query the state of the transaction after some implementation specific time (or upon recovery). If there's no log entry then the transaction service knows that the transaction MUST have rolled back and it'll indicate that to the XAResource query. If the XAResource implementation (or something acting on its behalf, such as the JBossTS XARecoveryModule) does not do this, then in this situation it will never find the transaction outcome. It can obviously make a heuristic choice, but I'd advise against that.

                      • 23. Re: XARecovery: Messaging integration with JBoss Transaction
                        marklittle

                         

                        "mskonda" wrote:
                        Mark

                        Is there a way I can invoke MessagingResourceRecovery class irrespective of finding no transactions in the object store?

                        The idea is - if RecoveryManager invokes this MessagingResourceRecovery, this class can provide the XAResource from which the RecoveryManager can call recover on it and problem solved!.



                        The recovery manager doesn't work in that way. Recovery is driven top-down (coordinator-to-participant) as well as bottom-up (participant-to-coordinator).

                        In the former case, the information about which participants to recover is maintained in the transaction log (essentially the references to the participants, which could be IORs if you're using JTS, or basic XAResource data if you're not, for instance). If there's no log entry, then there is absolutely nothing to recover: either all transactions committed (in which case there should be no outstanding participants querying the state of the transaction, or they'd be mentioned in a log entry somewhere), or the transactions rolled back (and any outstanding participants will find this out eventually).

                        In the latter case, the participant should record information about the transaction coordinator with which it was enlisted. During recovery, it (or rather the XARecoveryModule in the case of JBossTS) uses this information to query the state of the transaction by calling the coordinator instance. It'll either be told that the transaction committed or rolled back. Obviously the participant will then be committed or rolled back respectively.

                        JBossTS records information about all XAResources in the transaction log when it needs to. Likewise, it creates participant records within the log store to assist participant (XARecoveryModule driven) recovery: you don't need to do anything special here.

                        • 24. Re: XARecovery: Messaging integration with JBoss Transaction

                           


                          In the former case, the information about which participants to recover is maintained in the transaction log (essentially the references to the participants, which could be IORs if you're using JTS, or basic XAResource data if you're not, for instance). If there's no log entry, then there is absolutely nothing to recover:


                          Recovery doesn't exist unless the transaction log is available for the recovery module. Current JBossTS implemenation uses it's own object store for querying for transactional logs (TxControl.getStore) gets the object store in which a log is available).

                          Can this functionality be extended to use other transactional logs?

                          • 25. Re: XARecovery: Messaging integration with JBoss Transaction
                            marklittle

                            I don't think you quite understand: if the XAResources were registered with a JBossTS transaction AND that transaction did not finish committing, then there MUST be an entry in the JBossTS log IF 2PC was used. In addition, JBossTS will write information on behalf of XAResources for recovery into the log store.

                            • 26. Re: XARecovery: Messaging integration with JBoss Transaction
                              timfox

                              mskonda- i think you may be confusing the transaction log used by the transaction manager to keep a record of the participants, and the transaction log used by the JBossMessaging resource manager to store the state of prepared transactions.

                              These are quite separate. The former is handled by JBossTs and is nothing to do with JBossMessaging. The latter is handled by JBossMessaging where we use the database for this currently.

                              • 27. Re: XARecovery: Messaging integration with JBoss Transaction

                                I got it, thanks Tim and Mark for clarifications.

                                Tim, any chance we have an implementaion document for JBosMessagingg? I am more interetested in transactional part of it.

                                Thanks
                                Madhu

                                • 28. Re: XARecovery: Messaging integration with JBoss Transaction
                                  timfox

                                  Unfortunately the current design doco is out of date :(

                                  It is on our list to up to date but not sure when this is going to happen at the moment.

                                  • 29. Re: XARecovery: Messaging integration with JBoss Transaction
                                    timfox

                                    Unfortunately the current design doco is out of date :(

                                    It is on our list to up to date but not sure when this is going to happen at the moment.