4 Replies Latest reply on Nov 21, 2005 9:35 AM by timfox

    Generating unique transaction ids

    timfox

      In JBossMessaging there are possibly multiple active jms nodes in a cluster generating unique transaction ids.

      If we stick with an integer (int or long) transaction id we will have to implement some kind of transaction id interleaving to ensure uniqueness.

      E.g. server1 on startup initialises to max(tx_id)
      server2 on startup initialises to max(tx_id) +1
      server3 on startup initialises to max(tx_id) + 2
      each server increments id by n each time, where n is number of nodes in cluster.

      Alternative would be just to use the string value of a GUID as the tx id, so we can avoid all this.

      Cons of using a guid is that it takes up more space in db, plus look ups into index are probably slower.

      Comments anyone?

        • 1. Re: Generating unique transaction ids

           

          "timfox" wrote:

          Cons of using a guid is that it takes up more space in db, plus look ups into index are probably slower.


          No the main issue is maintaining the index (writes) not the lookup, although this depends
          upon the quality of the db implementation. ;-)

          There is an outstanding issue to in JBossMQ to create a JMS_DESTINATIONS
          table with integer->destination string (write through cached in memory)
          to improve the index and disk space usage.

          • 2. Re: Generating unique transaction ids

            You really want to use the internal db sequence generator
            with fallback to GUID where it isn't supported.

            • 3. Re: Generating unique transaction ids

              Questions:

              Who does the recovery if multiple nodes are using the same "transaction log"?

              How does a new node do the merge? The transaction log is a record of prepared/committed
              changes not the current state as seen by ongoing uncommitted operations on other nodes.
              e.g. delivery is not transactional, only acknowledgement.

              • 4. Re: Generating unique transaction ids
                timfox

                The whole question of how we recover queues/durable subscriptions and let them join/leave in a clustered environment is an interesting one.

                I believe Ovidiu is working on this as we speak. I am certainly curious as to how this is done.

                Currently the transactional state is isolated from the "comitted" state by using a column"STATE" (basically same as TXOP in jboss mq)

                One other thought; if we're going to have seamless failover I think we also need to replicate the global-local transaction map (TransactionRepository) between nodes.