1 2 Previous Next 19 Replies Latest reply on Oct 27, 2008 2:55 AM by Tim Fox

    Ordering Group -- Transaction Scenario Analysis (Typical Use

    Yong Hao Gao Master

      Ordering Group -- Transaction Scenario Analysis

      Abbrev Used:

      M1, M2, etc - Messages of the order of 1, 2, etc. that belong to an ordering group.
      R - The message receiver.
      TM - Transaction Manager
      XATx - A XA Transaction
      XAResJms - A XAResource from a JMS session.
      XAResDB - A XAResource from a DB connection.
      xid - Transaction ID of XATx.


      1) M1 arrives at R, R's onMessage(M1) is called.

      2) A XATx is started by the TM for the purpose of onMessage call.

      3) The onMessage() method accepts the M1 and does some updates on the target DB accordingly (within the XATx context).

      4) After onMessage() ends, TM starts to end the XATx.

      5) It first gets the XAResJms and XAResDB and issues prepare(xid) on them respectively.
      M1 at this point is still not completed and M2 is blocked.

      6) If prepare calls result in roll back, On XAResJms.rollback(), M1 will be released from the ordering group and M2 will subsequently available for delivery.

      7) If all prepare's replies are positive, TM goes on with commit.

      8) The commit() on XAResJms causes the M1 to be acknowledged and thus make M2's delivery possible.

      In this case, even the success of this commit doesn't mean that M1 is completed regarding ordering group rule, Simply because there may be other XA resources (XAResDB in this case) whose commit() may fail. JMS must not permit the deliver of M2 at this point of time and must be always aware of any recovery in the future. This means JMS server should not forget the M1 at this point.

      9) The commit() on XAResDB causes the updates to really happen.

      10) XAException from either of the above commits will fail the XATx and TM will initiates a recovery on behalf of this XATx. Eventually the commit() or rollback() will be issued again on problematic resources during recovery. Only when XATx completed in any way, M1 is finished and M2 becomes available. We need a way to monitor XATx, see my thought below.

      ----Summary-----

      We've analysed the Transaction Scenario above regarding the ordering group issue. We focus on the transactions on message receiving end because it is where the user mostly concerns. To guarantee ordering group in such scenario, we need to enhance the JMS server so that

      *) On XAResJms.rollback(), M1 will be released from the ordering group and M2 will subsequently available for delivery.

      *) On XAResJms.commit(), remember (in-mem and/or persist) the M1. We hold the M1 until we found the Transaction is completed. This can be achieved by obtaining the javax.transaction.Transaction object and keep calling Transaction.getStatus() (thread may be used). Until the status is STATUS_COMMITTED or STATUS_ROLLEDBACK, we release M1, otherwise we hold M1 and block M2. (but if server dies when keep querying status, we will lose the Transaction, how do we get it back after server is up? any API available?) If there is no way to do this, or not worth it, we just forget M1 simply after commit().

      *) Local transactions should be handled the similar way as if it is a one_phase commit XA transaction.

      *) Multiple Ordering Messages in transaction is impossible because ordering group only release one message at a time but the transaction requires all or none at a time.

        • 1. Re: Ordering Group -- Transaction Scenario Analysis (Typical
          Yong Hao Gao Master

          Correction:

          On XAResJms.rollback(), M1 will be PUT BACK to the ordering group and M2 stay blocked still.

          • 2. Re: Ordering Group -- Transaction Scenario Analysis (Typical
            Jonathan Halliday Master

             

            In this case, even the success of this commit doesn't mean that M1 is completed regarding ordering group rule, Simply because there may be other XA resources (XAResDB in this case) whose commit() may fail. JMS must not permit the deliver of M2 at this point of time and must be always aware of any recovery in the future. This means JMS server should not forget the M1 at this point.


            I respectfully disagree with that view. What you are suggesting is basically building automated heuristic outcome handling into the resource manager. It's incredibly difficult to do in a robust and correct manner and it's simply not worth the overhead.

            That said, there may, depending on the the isolation level used by the db, be a limited benefit to blocking M2 until an afterCompletion notification, provided it's done using in-memory (i.e. transient) data only.

            • 3. Re: Ordering Group -- Transaction Scenario Analysis (Typical
              Tim Fox Master

              It all seems a bit complex.

              If we just delay delivery of a message in a ordering group until all the previous ones are acked by the consumer then problem solved?

              This fits in with andy's work on message grouping...

              • 4. Re: Ordering Group -- Transaction Scenario Analysis (Typical
                Yong Hao Gao Master

                 

                "jhalliday" wrote:
                In this case, even the success of this commit doesn't mean that M1 is completed regarding ordering group rule, Simply because there may be other XA resources (XAResDB in this case) whose commit() may fail. JMS must not permit the deliver of M2 at this point of time and must be always aware of any recovery in the future. This means JMS server should not forget the M1 at this point.


                I respectfully disagree with that view. What you are suggesting is basically building automated heuristic outcome handling into the resource manager. It's incredibly difficult to do in a robust and correct manner and it's simply not worth the overhead.

                That said, there may, depending on the the isolation level used by the db, be a limited benefit to blocking M2 until an afterCompletion notification, provided it's done using in-memory (i.e. transient) data only.


                I agree. I'll go first the simple one. That is we forget M1 after the commit() on JMS XA resource and deliver M2.

                • 5. Re: Ordering Group -- Transaction Scenario Analysis (Typical
                  Yong Hao Gao Master

                   

                  "timfox" wrote:
                  It all seems a bit complex.

                  If we just delay delivery of a message in a ordering group until all the previous ones are acked by the consumer then problem solved?

                  This fits in with andy's work on message grouping...


                  Message grouping guarantee all the messages in a group goes to one consumer.
                  But ordering group is different, it guarantees messages being sent out one by one, it doesn't really care who receives the message.



                  • 6. Re: Ordering Group -- Transaction Scenario Analysis (Typical
                    Tim Fox Master

                    I'm probably not explaining this very well.

                    If I were implementing this, I can think of a way of doing it that seems very simple, does not require any extra consideration for transactions.

                    When delivering a message, you just prevent delivery of the next message with the same ordering group id unless its the same consumer or there are no consumers with same ordering group id unacked.

                    • 7. Re: Ordering Group -- Transaction Scenario Analysis (Typical
                      Tim Fox Master

                       

                      "gaohoward" wrote:

                      Message grouping guarantee all the messages in a group goes to one consumer.
                      But ordering group is different, it guarantees messages being sent out one by one, it doesn't really care who receives the message.



                      [Just discussed with Howard on IRC]

                      I think they're very closely related.

                      With message grouping, then all messages with the same group_id go to the same consumer as long as the consumer is not closed. If that consumer is closed the server will choose another consumer.

                      So it seems to me that message groups already provide ordering groups functionality.

                      The slight difference with message groups is all messages for that group go to the same consumer as long as that consumer is not closed.

                      Where, with the ordering groups, you would only need to send messages to the same consumer as long as there are no unacked for that consumer, so you could end up round robining.

                      Although in practice, the latter would not be strictly necessary to fulfil the requirements.

                      • 8. Re: Ordering Group -- Transaction Scenario Analysis (Typical
                        Yong Hao Gao Master

                         

                        "timfox" wrote:
                        "gaohoward" wrote:

                        Message grouping guarantee all the messages in a group goes to one consumer.
                        But ordering group is different, it guarantees messages being sent out one by one, it doesn't really care who receives the message.



                        [Just discussed with Howard on IRC]

                        I think they're very closely related.

                        With message grouping, then all messages with the same group_id go to the same consumer as long as the consumer is not closed. If that consumer is closed the server will choose another consumer.

                        So it seems to me that message groups already provide ordering groups functionality.

                        The slight difference with message groups is all messages for that group go to the same consumer as long as that consumer is not closed.

                        Where, with the ordering groups, you would only need to send messages to the same consumer as long as there are no unacked for that consumer, so you could end up round robining.

                        Although in practice, the latter would not be strictly necessary to fulfil the requirements.


                        Just had a look at message group impl (see GroupingRoundRobinDistributionPolicy) and I think I've already done what this class can be done for the ordering purpose. Plus I also have added the Message priority control in my code. So I decide to move on and focus on solving Tx issues.


                        • 9. Re: Ordering Group -- Transaction Scenario Analysis (Typical
                          Tim Fox Master

                           

                          "gaohoward" wrote:

                          Just had a look at message group impl (see GroupingRoundRobinDistributionPolicy) and I think I've already done what this class can be done for the ordering purpose. Plus I also have added the Message priority control in my code. So I decide to move on and focus on solving Tx issues.


                          Howard - could you rephrase? I'm not sure I understood you correctly.

                          Does the grouping approach we discussed not handle tx cases?

                          • 10. Re: Ordering Group -- Transaction Scenario Analysis (Typical
                            Yong Hao Gao Master

                            Tim, the message group is not transaction aware. As we discussed, it may still work under tx env. So far I haven't figured out an exception where it won't work. But I think it won't make much difference to get the message group code over to 1.4, as my code is already there and can do the same. So I'm thinking more tx scenarios to see if i missed any important cases. If I find (that won't take long i think) what we've discussed is already enough, then I will think about whether using mine or the message group.

                            • 11. Re: Ordering Group -- Transaction Scenario Analysis (Typical
                              Yong Hao Gao Master

                              Tim, the message group is not transaction aware. As we discussed, it may still work under tx env. So far I haven't figured out an exception where it won't work. But I think it won't make much difference to get the message group code over to 1.4, as my code is already there and can do the same. So I'm thinking more tx scenarios to see if i missed any important cases. If I find (that won't take long i think) what we've discussed is already enough, then I will think about whether using mine or the message group.

                              • 12. Re: Ordering Group -- Transaction Scenario Analysis (Typical
                                Yong Hao Gao Master

                                Sorry Tim, I posted twice, please delete one, thx.

                                • 13. Re: Ordering Group -- Transaction Scenario Analysis (Typical
                                  Tim Fox Master

                                   

                                  "gaohoward" wrote:
                                  Tim, the message group is not transaction aware.


                                  Does it need to be transaction aware?

                                  As we discussed, it may still work under tx env. So far I haven't figured out an exception where it won't work. But I think it won't make much difference to get the message group code over to 1.4, as my code is already there and can do the same.


                                  I would rather use code that we know works than use new code that does the same thing.




                                  • 14. Re: Ordering Group -- Transaction Scenario Analysis (Typical
                                    Tim Fox Master

                                    In other words, don't reinvent the wheel! ;)

                                    1 2 Previous Next