More locking improvements in Infinispan 5.1.0.BETA4
The latest beta in the Infinispan 5.1 "Brahma" series is out. So, what’s in Infinispan 5.1.0.BETA4? Here are the highlights:
A hugely important lock acquisition improvement has been implemented that results in locks being acquired in only a single node in the cluster. This means that deadlocks as a result of multiple nodes updating the same key are no longer possible. Concurrent updates on a single key will now be queued in the node that 'owns' that key. For more info, please check the design wiki and keep an eye on this blog because Mircea Markus, who’s the author of this enhancement, will be explaining it in more detail very shortly. Please note that you don’t need to make any configuration or code changes to take advantage of this improvement.
A bunch of classes and interfaces in the core/ module have been migrated to an api/ and commons/ module in order to reduce the size of the dependencies that the Hot Rod Java client had. As a result, there’s been a change in the hierarchy of Cache and CacheContainer classes, with the introduction of BasicCache and BasicCacheContainer, which are parent classes of existing Cache and CacheContainer classes respectively. What’s important is that Hot Rod clients must now code againts BasicCache and BasicCacheContainers rather than Cache and CacheContainer. So previous code that was written like this will no longer compile:
import org.infinispan.Cache; import org.infinispan.manager.CacheContainer; import org.infinispan.client.hotrod.RemoteCacheManager; ... CacheContainer cacheContainer = new RemoteCacheManager(); Cache cache = cacheContainer.getCache();
Instead, if Hot Rod clients want to continue using interfaces higher up the hierarchy from the remote cache/container classes, they’ll have to write:
import org.infinispan.BasicCache; import org.infinispan.manager.BasicCacheContainer; import org.infinispan.client.hotrod.RemoteCacheManager; ... BasicCacheContainer cacheContainer = new RemoteCacheManager(); BasicCache cache = cacheContainer.getCache();
import org.infinispan.client.hotrod.RemoteCache; import org.infinispan.client.hotrod.RemoteCacheManager; ... RemoteCacheManager cacheContainer = new RemoteCacheManager(); RemoteCache cache = cacheContainer.getCache();
We apologise for any inconvenience caused, but we think that the Hot Rod clients will hugely benefit from this vastly reducing the number of dependencies they need. * Finally, a few words about the ZIP distribution file. In BETA4 we’ve added some cache store implementations that were missing from previous releases, such as the RemoteCacheStore that talks to Hot Rod servers, and we’ve added a brand new demo application that implements a near-caching pattern using JMS. Please be aware that this demo is just a simple prototype of how near caches could be built using Infinispan and HornetQ.
Tags: locking API