Multiverse and the 2 Phase Commit

Currently I’m working on a 2 phase commit in Multiverse; a Java based Software Transactional Memory implementation. The cool thing about the 2 phase commit in Multiverse is that isn’t slow (something most developers fear when they hear about 2 phase commit). It only says that the transactions should do the commit in 2 parts:

  1. prepare: make sure that the transaction has no read/write conflicts and make sure that the sources are ‘locked’ so that a commit is going to succeed
  2. commit: does the actual writing of the changes

So if multiple transactions need to commit/abort atomically; the all need to be prepared first. If this succeeds, they all can continue to the commit (that is not going to fail). And if the prepare of one of the transactions fails, they are all aborted. A 2 phase commit in Multiverse can be done completely in memory in a single JVM without any network communication, so it is very very fast.


I’m still working on a nice ‘synchronization’ structure called the CommitGroup. The CommitGroup is the token that needs to be shared between all transactions that all need to commit atomically:

CommitGroup group = new CommitGroup();

When a transactions want to participate in the commit group, and are not able to complete it, you can do something like:


And if it is the transaction that is able to complete all the commits of the CommitGroup, you can do something like this:


Isn’t that cool? The 2 phase commit and the CommitGroup are going to be part of Multiverse 0.4 which is going to be released at the end of this month on the new location at Codehaus, including a complete new website with a big reference manual, tutorials, introductions and of course a lot of new features and performance improvements. The main focus is going to shift from creating a cool toy project, to something really usable like Hibernate.

13 Responses to Multiverse and the 2 Phase Commit

  1. Andrew Phillips says:

    “And if it is the transaction that is able to complete all the commits”

    How do you know that you are the transaction that the group is waiting for?

  2. pveentjer says:

    Hi Andrew,

    the Transactions that want to participate in the CommitGroup have to join with the waitForCommit and completeCommit.

    A transaction that ‘just’ wants to join but is not able to complete the whole set of transaction, does a waitForCommit. It automatically is placed in a waitset after the prepare was a success.

    A transaction that is able to complete the CommitGroup does a completeCommit. After the prepare was a success, all other ‘waitForCommit’ threads are notified and are going to store the pending changes.

    The cool thing is that each transaction will continue on its own thread (so it will also be executing the transaction lifecycle tasks on its own threads).

    Another cool thing is that this behavior is localized in the CommitGroup. So if in the future a different 2phase commit mechanism is needed (for example a non blocking one) this could be added without messing with the transaction interface.

    I’m still shaping a usable form. Atm this functionality will be available when the multiverse transaction api’s are used directly and can’t be used in the instrumentation. Perhaps I’m going to add this in the next release. But this functionality was needed for the Akka project which doesn’t rely on instrumentation.

  3. From a cursory look, a CommitGroup offers a subset of a Phaser’s[1] capabilities, and could be easily implemented in terms of the latter. Does it bring anything new to the table?


    • pveentjer says:

      Hi Dimitri,

      The commitgroup does transaction prepare and commit or abort, so it is totally made for multiverse (wont even compile without it since it depends on the transaction api)

      but i’ll have a look at the phasers

  4. Guy Pardon says:


    Looks cool. For the roadmap: if you’re interested in JTA then feel free to try ours. It is apache licensed too and integration should be easy.


    • pveentjer says:

      Hi Guy,

      thanks for replying. I have checked the Atomikos site before because I had the impression that Atomikos also working on a STM. Is that correct?

      The 2 phase commit in Multiverse for the moment should not be compared to distributed 2 phase commits (although both share a lot). The idea behind the Multiverse CommitBarriers (as they are called since the Multiverse 0.4 release) is that they provide a very easy mechanism to coordinate in memory transactions on a single machines. So it needs to solve a lot less problems than a traditional 2 phase commit (so no need to deal with system failure, network loss or xa protocol). It is very very lightweight. It is used in the Akka project to make sure than actors are able to commit together or none at all.

      I’m certainly interested in providing an JTA implementation to make Multiverse integrate easily with more traditional environment. But I have a hard time figuring out what the added value of Atomikos is. The acid stuff is the responsibility of the database or the JMS-Server (to name a few transactional resources). So what value is provided by Atomikos?

      • Guy Pardon says:

        Hi Peter,

        The added value of Atomikos when you are planning a JTA implementation is that we offer exactly that: a JTA implementation;-)


      • pveentjer says:

        Perhaps it is caused by my lack of deep understanding of the JTA architecture to realise how much effort it is. I have never written a JTA implementation or studied it in detail.

        How easy would it be to place Atomikos on top of the Multiverse Transaction API?

        Prepare/commit/abort are the most important functions and do the obvious things.

      • Guy Pardon says:


        At first sight, the Multiverse Transaction API seems to combine 2 roles: the participation in 2-phase commit and the commit role of a coordinator itself?

        Regardless, it is hard to say how long it would take, probably not very long though. In any case, if I were you then I would wait until there is concrete demand to do so.


      • pveentjer says:

        Hi Guy,

        the transaction doesn’t play the role of coordinator; that is the task of the CommitBarrier. The only thing the transaction does is to separate the commit in 2 steps:
        – check if there are conflicts and lock resources (preparation phase)
        – the actual writing of the changes (store phase)

        It is task of the CommitBarrier to coordinate multiple transactions so that they can all commit together; so the CommitBarrier is the one that calls prepare/commit on all cohorts. The advantage of this approach is that it keeps the Transaction api clean and that I can easily place different coordinator functionality on top.

        One of the future goals is to provide more enterprisy features like JTA. The big problem is time (I’m able to spend 30/40 hours a week in my spare time on Multiverse and at the moment is it mostly providing basic transactional datastructures like trees, queues etc and doing a lot of bytecode instrumentation).

  5. pveentjer says:

    At was not Atomikos, but Atomos stm šŸ™‚ Sorry for the confusion.

  6. Guy Pardon says:

    What exactly would you like to do with JTA? Coordinate things in Multiverse or rather have Multiverse enlist (take part) in appserver transactions?

    • pveentjer says:

      The last one šŸ™‚ I can already do the first one very very lightweight. But the idea is to transparently integrate STM when needed.

      One of the things I’m thinking about (working on a POC) is a storage solution for the STM.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: