JBoss Clustering Team @ JUG Berlin Brandenburg

The entire JBoss Clustering Team will be at the Berlin-Brandenburg JUG on Thursday, 19th November talking about JGroups, Infinispan and WildFly clustering.
If you are around, please come over to meet the team and share your thoughts and ideas.

The meetup is advertised here

Hot Rod Remote Events #4: Clustering and Failover

This blog post is the last in a series that looks at the forthcoming Hot Rod Remote Events functionality included in Infinispan 7.0. First article focused on how to get started receiving remote events from Hot Rod servers. The second article looked at how Hot Rod remote events can be filtered, and the third one showed how to customize contents of events.

In this last article, we'll be focusing on how remote events are fired in a clustered environment and how failover situations are dealt with.

The most important thing to know about remote events in a clustered environment is that when a client adds a remote listener, this is installed in a single node in the cluster and that this node is in charge of sending events back to the client for all affected operations happening cluster wide.

As a result of this, when filtering or event customization is applied, the org.infinispan.notifications.cachelistener.filter.CacheEventFilter and/or org.infinispan.notifications.cachelistener.filter.CacheEventConverter instances must be somehow marshallable. This is necessary because when the client listener is installed in a cluster, the filter and/or converter instances are sent to other nodes in the cluster so that filtering and conversion can happen right where the event originates, hence improving efficiency. These classes can be made marshallable by making them extend Serializable, or providing and registering a custom Externalizer for them.

Under normal circumstances, the code and examples showed in previous blog posts work the same way in clustered environment. However, in a clustered environment, a decision needs to be made with regards to how to deal with situations where nodes go down: If a node goes down that does not have the client listener installed, nothing happens. However, when the node containing the client listener goes down, the Hot Rod client implementation transparently fails over the client listener registration to a different node. As a result of this failover, there could be a gap in the event consumption. This gap is solved using one of these solutions:

State Delivery

The @ClientListener annotation has an optional parameter called includeCurrentState. When this is enabled and the client listener is registered, before receiving any events for on-going operations, the server sends ClientCacheEntryCreatedEvent event instances (for methods annotated with @ClientCacheEntryCreated) for all existing cache entries to the client. This offers the client an opportunity to construct some state or computation based on the contents of the clustered cache. When the Hot Rod client transparently fails over registered listeners, it re-registers them in a different node and if includeCurrentState is enabled, clients can recompute their state or computation to reinstate it to what it was before the failover. The downside of includeCurrentState is that it's performance is heavily dependant on the cache size, and hence it's disabled by default.

@ClientCacheFailover

Alternatively, instead of relying on receiving state, users can define a method with @ClientCacheFailover annotation that receives ClientCacheFailoverEvent as parameter inside the client listener implementation:

This method would be called back whenever the node that had this client listener has gone down. This can be handy for situations when the end users just wants to clear up some local state as a result of the failover, e.g. clear a near or L1 cache. When events are received again, the near or L1 cache could be repopulated again.

This callback method of dealing with client listener failover offers a simple, efficient solution to dealing with cluster topology changes affecting client listeners. Depending on the remote event use case, this method might be better suited that state delivery.

Final Words

This post marks the end of the remote event series. In future Infinispan versions, we'll continue improving the technology adding some extra features, and more importantly, we'll start building higher level abstractions on top of remote events, such as Hot Rod client Near Caches.

Cheers,
Galder

Cache and Cache Manger events in CDI

A long time ago, in a coffee bar far, far away, Infinispan met CDI. The two had the most amazing espressos, but they noticed that service was not as efficient as they wished. To help them out, the CDI support has been extended to include CDI Events.

Coffee Events

In case you haven't heard about CDI events, here is a really quick example:

When Waiter receives an order - he fires a CDI event. On the other hand Barista acts as a listener for ordered coffees (@CoffeeOrdered and @Observes). As a result Barista and Waiter are loosely coupled and moreover they don't know anything about each other.

Cache based Coffee Events

Now let's complicate this situation a little bit... Let's assume that when Waiter is passing an order to Barista, he might be actually busy processing another order. So let's introduce a little buffer between them - Waiter puts an order into the Cache and later on - Barista takes it and prepares our delicious coffee...

Beyond good espressos

As you can see - introducing CDI improved the service a lot. Now Waiter does not hurry Barista with the orders. This is why they serve the best espresso in the world there...

They have also a lot more time to think about other improvements (and to be honest... I think they will introduce CacheEntryModifiedEvent, CacheEntryRemovedEvent and CacheStartedEvent really shortly)... Or perhaps they'll find some other ideas in Infinispan's manual?

Hot Rod Remote Events #3: Customizing events

This blog post is the third in a series that looks at the forthcoming Hot Rod Remote Events functionality included in Infinispan 7.0. In the first article we looked at how to get started receiving remote events from Hot Rod servers. In the second article, we saw how Hot Rod remote events can be filtered providing key/value filter factories that can create instances that filter which events are sent to clients, and how these filters can act on client provided information.

This time we are going to focus on how to customize events sent to clients. Events generated by default contain just enough information to make the event relevant but avoid cramming too much information in order to reduce the cost of sending them. Normally, this information consists of key and type of event.

Optionally, the information shipped in these events can be customized in order to contain more information, such as values, or to contain even less information. This customization is done with org.infinispan.notifications.cachelistener.filter.CacheEventConverter instances which are created by implementing a org.infinispan.notifications.cachelistener.filter.CacheEventConverterFactory class. Each factory must have a name associated to it via the org.infinispan.filter.NamedFactory annotation.

When a listener is added, we can provide the name of a converter factory to use with this listener, and when the listener is added, the server will look up the factory and invoke getConverter method to get a org.infinispan.notifications.cachelistener.filter.CacheEventConverter class instance to customize events server side.

Here's a sample implementation which will send custom events containing value information back to clients for a cache of Integers and Strings:

In the example above, the converter generates a new custom event which includes the value as well as the key in the event. This will result in bigger event payloads compared with default events, but if combined with filtering, it can reduce its network bandwidth cost.

In another converter implementation, the user could decide to send back an event that contains no key or event type information. This would result in extremely lightweight events at the expense of richness of information provided by the event itself.

Plugging the server with this converter requires deploying this converter factory (and associated converter class) within a jar file including a service definition inside the META-INF/services/org.infinispan.notifications.cachelistener.filter.CacheEventConverterFactory file:

With the server plugged with the converter, the next step is adding a remote client listener that will use this converter. How to implement a listener for custom events is slightly different to the listeners we've seen in the last couple of blog posts because we know have to deal with customised events as opposed to the default ones. To do so, the same annotations are used as previous blog posts, but the callbacks receive instances of org.infinispan.client.hotrod.event.ClientCacheEntryCustomEvent<T>, where T is the type of custom event we are sending from the server:

Now it's time to write a simple main java class which adds the remote event listener and executes some operations against the remote cache:

Once executed, we should see a console console output similar to this:

Similar to events, converters can also act on client provided information, enabling converter instances to customize events depending on the information given when the listener was added. The API provides an extra parameter to pass in converter parameters when the listener is added. Given the similarities with filtering, this part is not covered by this blog post.

A final note on the marshalling aspects of this example. In order to facilitate both server and client writing against type safe APIs, both the client and server need to be aware of custom event type and be able to marshall it. Client side, this is done by an optional marshaller configurable via the RemoteCacheManager. Server side, this is done by a marshaller recently added to the Hot Rod server configuration.

In the next blog post in the Hot Rod remote events series, we will look at how to receive remote events in a clustered environment, how to deal with failover situations...etc.

Cheers,
Galder

Hot Rod Remote Events #2: Filtering events

This blog post is the second in a series that looks at the forthcoming Hot Rod Remote Events functionality included in Infinispan 7.0. In the first blog post we looked at how to get started receiving remote events from Hot Rod servers. This time we are going to focus on how to filter events directly in the server.

Sending events to remote clients has a cost which increases as the number of clients. The more clients register remote listeners, the more events the server has to send. This cost also goes up as the number of modifications are executed against the cache. The more cache modifications, the more events that need to be sent.

A way to reduce this cost is by filtering the events to send server-side. If at the server level custom code decides that clients are not interested in a particular event, the event does not even need to leave the server, improving the overall performance of the system.

Remote event filters are created by implementing a org.infinispan.notifications.cachelistener.filter.CacheEventFilterFactory class. Each factory must have a name associated to it via the org.infinispan.notifications.cachelistener.filter.NamedFactory annotation.

When a listener is added, we can provide the name of a key value filter factory to use with this listener, and when the listener is added, the server will look up the factory and invoke getFilter method to get a org.infinispan.notifications.cachelistener.filter.CacheEventFilterFactory class instance to filter events server side.

Filtering can be done based on key or value information, and even based on cached entry metadata. Here's a sample implementation which will filter key "2" out of the events sent to clients:

Plugging the server with this key value filter requires deploying this filter factory (and associated filter class) within a jar file including a service definition inside the META-INF/services/org.infinispan.notifications.cachelistener.filter.CacheEventFilterFactory file:

With the server plugged with the filter, the next step is adding a remote client listener that will use this filter. For this example, we'll extend the EventLogListener implementation provided in the first blog post in the series and we override the @ClientListener annotation to indicate the filter factory to use with this listener:

Next, we add the listener via the RemoteCache API and we execute some operations against the remote cache:

If we checkout the system output we'll see that the client receives events for all keys except those that have been filtered:

Finally, with Hot Rod remote events we have tried to provide additional flexibility at the client side, which is why when adding client listeners, users can provide parameters to the filter factory so that filter instances with different behaviours can be generated out of a single filter factory based on client side information. To show this in action, we are going to enhance the filter factory above so that instead of filtering on a statically given key, it can filter dynamically based on the key provided when adding the listener. Here's the revised version:

Finally, here's how we can now filter by "3" instead of "2":

And the output:


To summarise, we've seen how Hot Rod remote events can be filtered providing key/value filter factories that can create instances that filter which events are sent to clients, and how these filters can act on client provided information.

In the next blog post, we'll look at how to customize remote events in order to reduce the amount of information sent to the clients, or on the contrary, provide even more information to our clients.

Cheers,
Galder

Hot Rod Remote Events #1: Getting started

Shortly after the first Hot Rod server implementation was released in 2010, ISPN-374 was created requesting cache events to be forwarded back to connected clients. Even though embedded caches have had access to these events since Infinispan's first release, propagating them to remote clients has taken a while, due to the increased complexity involved.

For Infinispan 7.0, we've finally addressed this. This is the first post in a series that looks at Hot Rod Remote Events and the different functionality we've implemented for this release. On this first post, we show you how to get started with Hot Rod Remote Events with the most basic of examples:

Start by downloading the Server distribution for the latest 7.0 (or higher) release from Infinispan's download page. The server contains the Hot Rod server with which the client will communicate. Once downloaded, start it up running the following from the root of the server:

./bin/standalone.sh

Next up, we need to write a little application that interacts with the Hot Rod server. If you're using Maven, create an application with this dependency, changing version to 7.0.0.Beta1 or higher:

If not using Maven, adjust according to your chosen build tool or download the all distribution with all Infinispan jars.

With the application dependencies in place, we need to start to write the client application. We'll start with a simple remote event listener that simply logs all events received:
Now it's time to write a simple main java class which adds the remote event listener and executes some operations against the remote cache:

Once executed, we should see a console console output similar to this:

As you can see from the output, by default events come with the key and the internal data version associated with the current value. The actual value is not shipped back to the client for performance reasons. Clearly, receiving remote events has a cost, and as the cache size increases and more operations are executed, more events will be generated. To avoid inundating Hot Rod clients, remote events can either be filtered server side, or the event contents can be customised. In the next blog post in this series, we will see this functionality in action.

Cheers,
Galder

The first JUDCon Brazil experience

The first ever JUDCon Brazil was held a couple of weeks back and it was a real blast! Firstly, it offered a great opportunity to meet some members of the JBoss community which have been helping us push JBoss projects forward in this region of the world, such as Hanneli Tavante, Roberto dos Santos Wagner, ...etc. It was great sharing ideas, experiences...etc with them and coming up with new ideas!

As mentioned before in the post before the conference, I had two new presentations to deliver, one on JSR-107 specification on JCache API and Infinispan's implementation, and the other on Hibernate Second Level Cache with Infinispan. The JCache presentation went really well and all the live coding worked as expected.

The second presentation was the busier of the two, with a full room packed with Hibernate/JPA users waiting to hear how to scale up their applications. I got excellent feedback from both presentations and looking forward to giving these presentations in more user groups or conferences.

The presentations are not up yet, but I expect them to be posted online in the next few weeks. In the mean time, here are a couple of temporary links to the PDFs of my presentations:

• Bolttlenecks are out! Java Cache Standard (JSR-107) is in! (PDF)
• Scaling up Hibernate/JPA applications with Infinispan second-level cache (PDF)

The big news of the conference was for sure the announcement of JBoss Application Servers' new name: WildFly. We're actively working with them to make the most out of Infinispan :)

Cheers,
Galder

Infinispan coming to Brazil's JUDCon!!

Infinispan team is coming to São Paulo (Brazil) to present on multiple topics around caching, data grids and NoSQL in Brazil's first ever JBoss Users & Developers Conference (JUDCon). The event is being held over two days, on 19th and 20th of April.

On the 19th, Manik Surtani and Pete Muir will present on how to supercharge web applications using JBoss Data Grid. Expect a very lively presentation from these very seasoned presenters :)

Another presentation where you'll be able to see Infinispan in action is in Shekhar Gulati's "Closed PaaS to Open PaaS : Migrate GAE Applications to OpenShift Using CapeDwarf" and Randall Hauch's "Elastic Consistent NoSQL Data Storage with ModeShape 3" talk, both on the 19th of April, where Shekhar and Randal will demonstrate JBoss projects using Infinispan heavily.

On 20th of April, I'll be speaking about scaling up Hibernate/JPA applications with Infinispan second-level cache. Even if the Infinispan caching provider was created almost 4 years ago, this is the first time I'm presenting about it. Really looking forward to that.

Finally, I'll also give the first ever presentation on Infinispan JCache (JSR-107) API implementation, which will be mostly a live coding session showing different bits about JCache API and the extra capabilities JCache users get from using Infinispan implementation.

Cheers,
Galder

Back from JUDCon China 2012

JUDCon China was held for the first time last week in Beijing, and it was a blast!

I had never been to China before, let alone a conference there, so it was interesting to compare it with other conferences around the world. The use of simulaneous translators meant those giving presentations in English had to pace themselves a bit more so that translators would have time to catch up. There's was a good bunch of presentation given by native Chinese speakers too, so the audience got the chance to attend more interactive sessions too.

During this two-day developer conference, I was showing Infinispan's capabilities as a powerful cache bulding a transactional EE application that neeeded to scale up live. In this presentation, which combines Infinispan with JSF and CDI, I showed how to go from a basic temporary cached, to a clustered cache that used consistent hashing to distribute data, showing the ability to scale up and failover. This presentation which was given shortly after the keynote on the first day generated a lot of interest in the audience, with a lot of users wanting to find out how we compared with other existing cache and data grid providers. This was a great opportunitiy to introduce the rest of Inifnispan talks that were happening that day and the day after, where they could learn more Infinsipan's other features as a data grid: i.e. querying, geographic failover...etc.

My second presentation that same day was about querying Infinispan based data grids. The room was packed for this one, and in the presentation I talked about how Infinispan's map/reduce functions can take advantage of the paralellism available in cluster to resolve basic queries, and how Infinispan's contents can be indexed using the query module and queried via Hibernate Search or Apache Lucene APIs. Finally, I did a little overview of higher level APIs offering further querying possibilities (i.e. ModeShape, Hibernate OGM). As pointed out by Ales, the lead of CapeDwarf team, I somehow forgot to add his project, which offers the possibility of running Google App Engine on top of JBoss Application Server, which uses Infinispan and offers different querying possibilities too. Don't worry Ales, we'll sort it out for this presentation's next outing :)

For those who attended, the presentations should be uploaded to the JUDCon China website within the next few weeks.

Not all was presentations though, we also had the chance to socialise with attendees and other Red Hat employees in China. After all talks finished the first day, Jim Ma and Yong Yang did a fantastics demo of a cluster of JBoss Application Server 7 instances running on Rasperry PIs, and the audience had the opportunity to win one a Rasperry Pi too!

If you're thinking of going to China, you can't leave without trying a hot pot place! On Friday night we went to a Hai Dai Lao Hot Pot restaurant for food, and from a culinary perspective, it was the best food I had during my China stay. Hot Pot restaurants have this concept of cooking different meats, vegetables and noodles in two hot pots, one spicy and the other not. On top of that, you get the chance to mix up some cold sauces yourself (sesame oil, coriander, nuts, chillies,,,etc) and mix that with the cooked meat/veg. Unfortunately, one of our colleagues who had a nut allergy had to be rushed to hospital, but it was all Ok in the end :).

From here I'd like to thank Cindy Dong, Jervis Liu, Jim Ma, Christina Lin and many others that helped us, Aliens (according to Chinese Immigration prospects), feel like at home :). Can't wait to get back to China.

Cheers,
Galder

Back from Devoxx

This year - as always - Devoxx was a great conference! Not only the quality of the presentation (including quite some delivered by my fellows from Red Hat)  but also the chance to meet and discuss with industry experts. And the Hackergarten was one of the this great networking places.
We had a long chat with Marius Bogoevici on a nice extension of the Ticket Monster Tutorial for Infinispan, so that users looking for an sample integration application would have a good starting point. Also Duncan Doyle  contributed a nice demo of the cross-site replication functionality added in Infinispan 5.2 and Guillaume Scheibel implemented a Mongo DB cache store extension: awesome stuff!
All in all great conference and very good chance for us to get in touch with our community!
Cheers,
Mircea

Infinispan @ Devoxx 2012 Hackergarten

Just came back from Devoxx, and once again it didn't let me down! Great conference, with awesome talks, and fantastic networking opportunities (hackergarten, party...etc). As far as Infinispan is concerned, I joined the Hackergarten on Tuesday morning to try lure some contributors into our project :).

One of the most promising opportunities came from Alex Soto, who's founder and lead of NoSQLUnit, which is a JUnit extension that helps you write NoSQL unit tests. He already has support for a number of NoSQL engines and he was explaining me the challenges of supporting multiple engines. We also discussed the possibility of supporting Infinispan as well :D.

During the Hackergarten I also met Andrés Almiray, which is the Griffon founder, and we briefly discussed the possibility of adding integrating Infinispan's Hot Rod client with Griffon clients. Unfortunately we didn't have time to get into some coding, but since he lives close-by and he organises Hackergartens in Basel, I might pop in next time around and sit down with him to work on this integration :).

Can't wait for next Devoxx!!

Cheers,
Galder

Devoxx here we come!

If you're interested in data grids and especially in general and measuring data grids performance in particular then come to my presentation at this year's Devoxx.

Manik Surtani is getting funny (literally!) with a gig suggestively named "Will you Map/Reduce my cloud" and Galder Zamarreno brings the polyglot JBoss at Devoxx.

We'll also be around the Red Hat boot in case you want to have an Infinispan related discussion or just to say hi.

Cheers,

Mircea

Infinispan coming to JUDCon China 2012

The Infinispan team will be well represented in the forthcoming JUDCon China 2012 conference to be celebrated in Beijing on the 29th and 30th of November with no less than 9 talks!

We'll be covering all sorts of topics:
- Building transactional Infinispan applications
- Performing rolling upgrades for Infinispan based cluster
- Scaling Hibernate/JPA applications using Infinispan-based second level cache
- Effective querying of Infinispan data grids
- Measuring performance of data grids
- ...etc

So, if you're interested in data grids, caching or Infinispan, come and join us!! It's gonna be a fun a couple of days. Can't wait :)

Cheers,
Galder

Infinispan @JBoss One Day Talk in Munich!

If you happen to be in Munich for this year's JBoss One Day Talk and Infinispan is something you want to know more about then come and see the Infinispan presentation! I'll also be hanging around so just ping me and come for a chat.

Cheers,
Mircea

JBoss Data Grid lands in Red Hat Summit!

It's just over a week since Red Hat Summit/JBoss World 2012 finished and it was a great pleasure to be part of it. Heiko Rupp and I were speaking about "Effectively Manage & Monitor Red Hat JBoss Data Grid Nodes" where we presented JDG and JON at a high level and then we showed a demo of both products interacting with each other. The presentation's slides are now available for download.

I was not the only one speaking about JBoss Data Grid. Both Manik, the Infinispan project lead, and Alan Santos, the product manager for Infinispan, were also delivering talks on JBoss Data Grid. Although their presentations are not up yet, you'll be able to download them from here.

I also met some Infinispan customers, such as Erik who's been using Infinispan at a well known telecommunications company, or two of the lead technical guys at a well known Geneva bank. We had some great conversations where we were able to synch up our roadmap with them to make sure any requirements they had are met in the future.

Of the presentations I attended, I was particularly impressed by Pete and Marius' 10 minute demo on going from 0 to a fully fledged mobile application running on top of AS7 in OpenShift in the "What's New in Java Frameworks for Web, Cloud, & Mobile" BOF. I hope it was recorded cos it was very impressive stuff.

It was a great week and once again it was a pleasure to be part of the Red Hat Summit and JBoss World :)

Cheers,

Galder

The JBoss Enterprise Data Grid tour!!

It's exciting times at the Infinispan team! Here's some of my highlights of the last few weeks and events coming up.

JBoss Enterprise Data Grid (based in Infinispan) presented in Spain's Red Hat JBoss Open Forum 2012

Yesterday I was in Madrid at Red Hat's JBoss Open Forum 2012, where I presented about JBoss Enterprise Data Grid and Clustering in JBoss Enterprise Application Plattform 6. 

This was a great opportunity to introduce these new products to a Spanish audience, and as with everything in Spain, if you present in the native language, people understand things better and are more likely to get a better impression. 

Might sound odd, but presenting this stuff in another language other than English, such as Spanish, is rather difficult even if you're a native speaker. If you've developed software in English, you're used to speaking about it in that language, but if you switch and you have to talk about in another language, getting the fluency required to tell a story (i.e. present something) takes a lot of preparation (write up notes in that language!) and above all, rehearsing.

The effort was worth it though! Having finished my first presentation, the JBoss Enterprise Data Grid one, I was non-stop talking to the Spanish sales force, potential Spanish customers...etc for the rest of the day, until I had to present again.

Last time I attended a JBoss middleware event in Spain was in Barcelona in 2006. A long time has passed since then, but what Red Hat Spain's JBoss Forum shows is that JBoss Middleware is back in the Iberian peninsula, and it's there to stay for a long time!!

Special thanks to Lucas Ponce who helped out massively with the live demos of both JBoss Enterprise Data Grid and JBoss Enterprise Application Plattform 6, and thanks to the rest of Red Hat Spain team who invited me to speak at the event.

JBoss World/Red Hat Summit and JUDCon in Boston

Heiko Rupp and I will be speaking about JBoss Enterprise Data Grid monitoring with JBoss Operations Network, which we're both hugely looking forward to! So, if you're around, don't miss the talk next Thursday at 2.30pm EDT (abstract can be found here)

Cheers,

Galder

Back from Berlinbuzzwords

I'm back from the berlin buzzwords conference where I've been talking about the datagrids performance. 
I've been told by several people how good this conference was - but even so I was very surprised by the quality of both the presenters and audience. The conference is very focused on data relates topics (scale, search, store) so it was great picking up the brains of so many data enthusiasts. The beer wasn't that bad either. 
A big thanks to the organizers for the this excellent event and hope that infinispan be part of next year's agenda.


Cheers,
Mircea

On datagrid performance @ Berlinbuzzwords

I will be talking about datagrid performance and capacity planning and Radargun at this year's edition of Berlin Buzzwords, 4-5 June (I'll let you guess the location). My very first time at this conference but the amount of positive feedback I received about it was huge, so really looking forward to it!

Cheers,
Mircea

Infinispan @ MOW 2012

A couple of weeks back I was speaking about Infinispan and Radargun at MOW 2012. Although this conference was originally focused on Oracle products, for a over a year now, Miracle have been expanding into other territories, such as Microsoft and Java middleware. However, there's still some work to be done in this area in order to make this a must-go conference for Java developers. Max Andersen and Thomas Heute were presenting as well on topics such as: Ceylon, JBoss AS7 and OpenShift.

If you want to find out more about Infinispan, don't miss Mircea Markus at Berlin Buzzwords 2012, at the beginning of June.

Cheers,
Galder

Back from Portugal with goodies

The trip started in Coimbra where Sanne Grinovero and I discussed about Infinispan and OGM at the Portugal JUG. The interest was obvious from the amount of questions and the discussions that followed and ended up late in the night. A big thanks to Samuel Santos for organising this!

The trip then continued in Lisbon where we meet the CloudTM team for two good days of hacking and brainstorming.  The results are a set of awesome features the CloudTM is about to contribute to Infinispan, especially around transactions:

• Total Order Broadcast (TOB) - is a transaction protocol for replicated caches built on atomic broadcast. It relies on JGroups'  SEQUENCER protocol for achieving total order. The benchmarks ran comparing it with the current 2PC based transaction protocol are rather promising and we hope to integrated it in our 5.2 release
• Total Order Multicast (TOM) - is simplistically put TOB for distributed caches. This is the next in pipe after TOB to be integrated. Again, preliminary performance comparisons look rather promising
• The  CloudTM also extended Infinispan's transactions to support one-copy serializability (that's a fancy name for SERIALIZABLE  transactions in replicated systems). The implementation is based on keeping multiple data version of data for each entry together with some housekeeping code. More on this to come!

Big thanks to CloudTM team for their effort and all the great ideas (and patches!!) they submitted to Infinispan! It was a great meeting with very good results and burning whiteboards (see below)!

Cheers,
Mircea