6 Replies Latest reply on Sep 10, 2008 8:39 AM by timfox

    Replay transaction on XA

    clebert.suconic

      As I was talking to Andy today, when we replay the Transaction we need to find MessageReferences for deletedMessages, and we only store the ID of the message (never the queueID what is required to find the MessageReference).


      There are 4 possible solutions for this:

      I - Change delete method to also store a queueID, supporting the replay operation.
      (Performant, but I'm not sure if we should do it)


      II - Scan for the Message on the Queues associated with the address. (But that's a problem if you had 1000 queues). But reload with PreparedTransaction shouldn't happen too oftenly.. so I'm not sure if that would be a problem.

      (This is the option I would choose. We can do it with minimal changes)

      III - Aways record an update with the ID. But that would have other implications on the journal. (Performance and logical)
      (I'm aways against adding new records just, so I don't like this option)


      IV - Use the TransactionData associated with the prepareTransaction, to store extra information about ACKs (besides just the XID).
      (This is also performant... that should be one of the options evaluated).

        • 1. Re: Replay transaction on XA
          ataylor

          Regarding the 4 options.

          1. A delete record shpould only mark a previous record as deleted and not contain extra info.

          2. We still dont have the address to scan the queues for.

          3. by this i think you mean always add an ack_message, currently we only add an ack_message if it isn't the last durable reference, otherwise we only add a delete record which has no extra info on it.

          4. Again, i dont think this is correct, we need to remove the xid info anyway.

          The most logical way, altho maybe not performant, is 3. If we're acking a message we should always write an ack record, but this means we are writing n + 1 record rather than n records where n is the number of durable references.

          • 2. Re: Replay transaction on XA
            ataylor
            • 3. Re: Replay transaction on XA
              timfox

              I have gone through and reviewed the journal as promised.

              I have just committed some changes, please can you look through, I have left various comments in the code.

              Most of the changes were minor or cosmetic - there are still some unresolved questions (see comments), also more code comments are needed in places - e.g. record formats.

              There are also some methods that are only used by tests (append methods taking byte[]) the tests should use the public interface methods which use encodingsupport.

              I also removed a few remaining references to xids.

              Now, regarding the issue at hand:

              I prefer option 1). currently add and update records can take an arbitrary encoding support for data, we should just extend this for delete too. So for delete, we write the queue id, as we currently do for updates.

              This is the most symmetrical solution imho.

              Regarding adding extra data for xids in the prepare. After thought I think this is acceptable as long as no reference to xids in the code (I have removed them all now) - it's just extra data.

              • 4. Re: Replay transaction on XA
                ataylor

                ok, ive implemented no. 1 locally, I have an issue with paging that i need to talk to clebert about when he's about and a few tests to fix then I'll check in.

                • 5. Re: Replay transaction on XA
                  clebert.suconic

                   

                  "timfox" wrote:

                  There are also some methods that are only used by tests (append methods taking byte[]) the tests should use the public interface methods which use encodingsupport.


                  There a bunch of tests still referring the old method. I will make the tests to use an Encodingsupport that will use a byteArray and remove the test.

                  I prefer option 1). currently add and update records can take an arbitrary encoding support for data, we should just extend this for delete too. So for delete, we write the queue id, as we currently do for updates.

                  This is the most symmetrical solution imho.



                  This would be an update-for-delete record?

                  Could we add this to the API?
                  delete(long txID, long recordID, EncodingSupport data);


                  Then internally we would use the new update-to-delete record-type.

                  • 6. Re: Replay transaction on XA
                    timfox

                     

                    "clebert.suconic@jboss.com" wrote:


                    This would be an update-for-delete record?

                    Could we add this to the API?
                    delete(long txID, long recordID, EncodingSupport data);


                    Then internally we would use the new update-to-delete record-type.


                    Yes, that's the kind of thing I was thinking of.