Transaction remake in Infinispan 5.1

If you ever used Infinispan in a transactional way you might be very interested in this article as it describes some very significant improvements in version 5.1 "Brahma" (released with 5.1.Beta1):

• starting with this release an Infinispan cache can accessed either transactionally or non-transactionally. The mixed access mode is no longer supported (backward compatibility still maintained, see below). There are several reasons for going this path, but one of them most important result of this decision is a cleaner semantic on how concurrency is managed between multiple requestors for the same cache entry.


• starting with 5.1 the supported transaction models are optimistic and pessimistic. Optimistic model is an improvement over the existing default transaction model by completely deferring lock acquisition to transaction prepare time. That reduces lock acquisition duration and increases throughput; also avoids deadlocks. With pessimistic model, cluster wide-locks are being acquired on each write and only being released after the transaction completed (see below).

Transactional or non transactional cache?

It's up to you as an user to decide weather you want to define a cache as transactional or not. By default, infinispan caches are non transactional. A cache can be made transactional by changing the transactionMode attribute:

transactionMode can only take two values: TRANSACTIONAL and NON_TRANSACTIONAL. Same thing can be also achieved programatically:

Important:for transactional caches it is required to configure a TransactionManagerLookup.

Backward compatibility

The autoCommit attribute was added in order to assure backward compatibility. If a cache is transactional and autoCommit is enabled (defaults to true) then any call that is performed outside of a transaction's scope is transparently wrapped within a transaction. In other words Infinispan adds the logic for starting a transaction before the call and committing it after the call.

So if your code accesses a cache both transactionally and non-transactionally, all you have to do when migrating to Infinispan 5.1 is mark the cache as transactional and enable autoCommit (that's actually enabled by default, so just don't disable it :)

The autoCommit feature can be managed through configuration:

or programatically:

Optimistic Transactions

With optimistic transactions locks are being acquired at transaction prepare time and are only being held up to the point the transaction commits (or rollbacks). This is different from the 5.0 default locking model where local locks are being acquire on writes and cluster locks are being acquired during prepare time.

Optimistic transactions can be enabled in the configuration file:

or programatically:

By default, a transactional cache is optimistic.

Pessimistic Transactions

From a lock acquisition perspective, pessimistic transactions obtain locks on keys at the time the key is written. E.g.

When cache.put(k1,v1) returns k1 is locked and no other transaction running anywhere in the cluster can write to it. Reading k1 is still possible. The lock on k1 is released when the transaction completes (commits or rollbacks).

Pessimistic transactions can be enabled in the configuration file:

or programatically:

What do I need - pessimistic or optimistic transactions?

From a use case perspective, optimistic transactions should be used when there's not a lot of contention between multiple transactions running at the same time. That is because the optimistic transactions rollback if data has changed between the time it was read and the time it was committed (writeSkewCheck).

On the other hand, pessimistic transactions might be a better fit when there is high contention on the keys and transaction rollbacks are less desirable. Pessimistic transactions are more costly by their nature: each write operation potentially involves a RPC for lock acquisition.

The path ahead

This major transaction rework has opened the way for several other transaction related improvements:

• Single node locking model is a major step forward in avoiding deadlocks and increasing throughput by only acquiring locks on a single node in the cluster, disregarding the number of redundant copies (numOwners) on which data is replicated


• Lock acquisition reordering is a deadlock avoidance technique that will be used for optimistic transactions


• Incremental locking is another technique for minimising deadlocks.

Stay tuned!
Mircea

Catch me if you can... at Soft Shake or JUDCon!

As you're probably well aware, the Infinispan team is delivering talks all around the world. If you're in the US and you want to find out more Infinispan/EDG, Manik will be speaking at JavaOne, but if like me you're staying out in Europe, why not come to Soft Shake in Geneva?

Soft Shake is an IT conference being held in Geneva on October 3rd and 4th and I'll be speaking about data grids and data caching with Infinispan on the 3rd. In fact, I'll be speaking twice! At 1pm you'll see me doing an introduction to data grids and data caching, and at 5pm I'll be delving into the data grid vs database debate.

So, if any of this topics interest you, come and join us at Soft Shake! It's gonna be fun :)

And that is not all! I'll be one of the Infinispan team members speaking in JUDCon London at the end of October. The agenda is now live and you'll see me talking about near caching on the 31st of October. Don't miss it!

Cheers,
Galder

Next Infinispan 5.1.0 alpha hits the streets!

Infinispan 5.1.0.ALPHA2 "Brahma" is out now containing a consolidated push-based approach for both state transfer in replicated caches and rehashing in distributed ones. The new changes don't have great impact on the distributed cache users, but for those that relied on state transfer, it's definitely good news :). State transfer now works in such way that when a node joins, all nodes in the cluster push state to it, rather than the new node getting it from the cluster coordinator. As a result of this, the task of providing the state is paralellized, reducing the load on state providers.

On top of that, this Infinispan release is the first one to integrate JGroups 3.0 which brings plenty of API changes that simplifies a lot of the Infinispan/JGroups interaction. If you want to find out more about the new JGroups version, make sure you check Bela's blog and the brand new JGroups manual.

Please keep the feedback coming, and as always, you can download the release from here and you get further details on the issues addressed in the changelog.

Cheers,
Galder

When Infinispan meets CDI

Since version 5.0 (Pagoa) Infinispan has a new module. This module is a portable CDI extension which integrates Infinispan with the CDI programming model. Here are some highlights of what is provided:

• full integration with Java EE 6
• typesafe cache (and cache manager) injection
• JCACHE annotations support

Please note that this module is a technology preview and its API can still change. Next let's discuss some of its details.

Typesafe injection and configuration of cache

The first feature you can use out of the box is the typesafe injection of the Cache and the CacheManager. Without any configuration you can inject the default cache, as well as the cache manager used by the extension. This injection can be performed in any bean managed by Java EE like EJB, Servlet and CDI beans. The only thing to do is to use the @Inject annotation:

Please note that the cache injection is typed. In this case, only String typed Java objects could be added as key and value.

It's also possible to configure the injected cache using CDI. The first step is to create a CDI qualifier, and then create the cache configuration producer, annotated with @ConfigureCache. The qualifier is used to qualify the injection point and the cache configuration producer:



In the same way, a cache can be defined with the default configuration of the cache manager in use, using a producer field:



One advantage of this approach is that all cache configurations of the entire application can be gathered together into a single Configuration class.

The Infinispan CDI extension provides a cache manager with a default configuration (and it is used by default). You can also override the default configuration (used by the default cache manager), as well as the default cache manager. You can find more information here.

JCache annotations support

JCache (aka JSR-107) is famous as the oldest open JSR. However, this JSR has recently seen extensive progress, and is a candidate for inclusion in Java EE 7 (JSR-342).

This specification defines a standard caching API to work with a standalone cache, as well as a distributed cache. An interesting part of the specification are the annotations which are designed to solve common caching use cases. Some of the annotations defined by this specification are:

• @CacheResult caches the result of a method call
• @CachePut caches a method parameter
• @CacheRemoveEntry removes an entry from a cache
• @CacheRemoveAll removes all entries from a cache

The following example illustrates the use of these annotations:

The Infinispan CDI extension adds support for these annotations. The only thing to do is to enable the CDI interceptors in your application beans.xml - you can find more information here.

Infinispan CDI and JBoss AS 7

With JBoss AS 7, you can setup an Infinispan cache manager in the server configuration file. This allows you to externalize your Infinispan configuration and also to lookup the cache manager from JNDI, normally with the @Resource annotation. This post has more details on the subject.

As we mentioned earlier, you can override the default cache manager used by the Infinispan CDI extension. To use a JBoss AS 7 configured cache, you need to use the cache manager defined in JBoss AS 7. You only need to annotate the default cache manager producer with @Resource. Simple!



Now, you can inject the cache defined in JBoss AS 7 as we described earlier.

What's next?

Here is a highlight of the features you will see soon.

• support for all JSR 107 annotations - @CachePut, @CacheDefaults
• support for remote cache
• ability to listen Infinispan events with CDI observers
• and more - let us know what you want ;-)

As usual you can open issues and features request on the Infinispan JIRA (component CDI Integration).

Feel free to open a topic in the Infinispan forum if you need help.

The Infinispan CDI documentation is here.

To see the Infinispan CDI extension in action you can browse and run the quickstart application here or watch this screencast.

Enjoy!


About the author
 
Kevin Pollet is a software engineer at SERLI a Consulting & Software Engineering company based in France. He's an Open Source advocate and contributes on many projects such as Infinispan and Hibernate Validator, both at SERLI and at home. He is also involved in the Poitou-Charentes JUG and has spoken in many JUG events. He enjoys attending Java events like JUDCon, JBoss World and Devoxx.

Infinispan 5.1.0.ALPHA1 released: Distributed Queries are here!

Having released Infinispan 5.0.1.FINAL yesterday, today is the turn of releasing Infinispan 5.1.0.ALPHA1 "Brahma". This is the first in a series of alpha releases which will give Infinispan users the chance to play with the newest features. Here're some highlights of what's included in this release:

• Thanks to Israel Lacerra, Infinispan now supports fully distributed queries which allows queries to be parallelised across all nodes. Creating a distributed query is very easy, simply call SearchManager.getClusteredQuery. Please note that this feature is experimental and the API is likely to change before the final release.
• Infnispan Query module uses Hibernate Search 4 now.
• In Infinispan 5.0, we introduced the possibility of executing operations against a cache in such way that class loading could occur with a user-provided classloader. In this new release, we've extended the use case to allow data that's stored in binary format to be unmarshalled with the given classloader. This is particularly handy for those users that are deploying Infinispan in modular, or OSGI-like environments. For more information, check AdvancedCache.with(ClassLoader) API.

Please keep the feedback coming, and as always, you can download the release from here and you get further details on the issues addressed in the changelog.

By the way, remember that members of the Infinispan team will be speaking in events such as JavaOne, SoftShake, JUDCon London, Devoxx...etc across the globe. Don't miss them!

Cheers,

Galder

Infinispan 5.0.1.FINAL is out!

Thanks to everyone that downloaded Infinispan 5.0.0.FINAL in the last month. We've had tremendous feedback and as a result of that we've just released Infinispan 5.0.1.FINAL to address some of the most important issues reported. These issues are primarily around distribution clustering mode and rehashing. So, if you're using any of these features, I'd strongly recommend that you upgrade as soon as possible.

Please keep the feedback coming, and as always, you can download the release from here and you get further details on the issues addressed in the changelog.

Finally, we know have a documentation space fully dedicated to Infinispan 5.0. Make sure you check it out!

Cheers,
Galder

JavaOne 2011 and Devoxx 2011

I never got around to blogging about this when my talks were accepted for JavaOne this year, but it's about time.

I have a conference session titled "A Tale About Caching (JSR 107) and Data Grids (JSR 347) in Enterprise Java" and a BoF session focused on JSR 347 titled "Making Java EE Cloud-Friendly: JSR 347, Data Grids for the Java Platform", which I will be delivering with fellow Infinispan developer, JBoss rockstar and overall nice guy Pete Muir.

Later on in the year, I will also be running a University talk at Devoxx in Antwerp, titled "A real-world deep-dive into Infinispan".  This too will be with Pete and Mircea Markus, another core Infinispan developer.

This will be a great chance to learn more about Infinispan, data grids, JSR 107 and JSR 347, so if you are attending these conferences, make sure you add these talks to your agenda!  :-)

Cheers
Manik