Performance Zone is brought to you in partnership with:

Manik Surtani is a core R&D engineer at JBoss and project lead on JBoss Cache. He has a background in artificial intelligence and neural networks, a field he left behind when he moved from academic circles to the commercial world. Since then, he's been working with Java-related technologies, first for a startup, focusing on knowledge management and information exchange. He later worked for a large London-based consultancy as a tech lead focused on e-commerce applications on large J2EE and peer-to-peer technology. Manik is a strong proponent of open source development methodologies, ethos, and collaborative processes, and often speaks at Java User Groups around the world. Manik is a DZone MVB and is not an employee of DZone and has posted 39 posts at DZone. You can read more from them at their website. View Full User Profile

Faster transaction protocols in Infinispan!

04.30.2013
| 1462 views |
  • submit to reddit
The total order based protocol is a lock free multi-master scheme (i.e. all the Infinispan nodes are able to execute read and write transactions) commit protocol. This protocol relies on the concept of totally ordered delivery of messages which, informally, implies that each node which delivers a set of messages, delivers them in the same order. This protocol comes with this advantages.
  1. transactions can be committed in one phase, as they are delivered in the same order by the nodes that receive them.
  2. it mitigates distributed deadlocks.
The weaknesses of this approach are the fact that its implementation relies on a single thread per node which delivers the transaction and its modification, and the slightly higher number of messages exchanged by JGroups. Thus, this protocol delivers best performance in scenarios of high contention, in which it can benefit from the single-phase commit and the deliver thread is not the bottleneck. Currently, the Total Order based protocol is available only in transactional caches for replicated and distributed modes and it is available in Infinispan 5.3.0 Alpha1. If you are interested in know more, please take a look at the user documentation where it is explained in more details how it behaves and how you can configure it. Since this is a recent work, if you find any incorrect behavior please create a JIRA. Following we have some benchmark evaluation comparing the total order based implementation with the locking based implementation in two different scenarios:
  • Contention: 1000 keys in a shared pool, 8 threads per node and 5 writes (on average) per transaction;
  • No Contention: 1000 keys in a thread private pool, 8 threads per node and 5 writes (on average) per transaction.




Published at DZone with permission of Manik Surtani, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)