Triple cachestore release: Cloud, MongoDB and Cassandra

Today we present to you a trifecta of cache store releases which align to Infinispan 9.x

Cassandra Cache Store

The Cassandra cache store now implements the publishEntries/publishKeys methods.

Cloud Cache Store

The Cloud cache store uses the Apache jclouds library to store data on cloud storage providers such as Amazon’s S3, Rackspace’s Cloudfiles or any other such provider supported by JClouds.
The store has been updated to Infinispan 9.x's persistence SPI and uses jclouds 2.1.x

MongoDB Cache Store

This cache store has also been updated to the Infinispan 9.x persistence SPI.

You can get documentation and maven coordinates from our Cache Store page

Cache Store Batch Operations

Infinispan 9.1.x introduces batch write and delete operations for cache stores. The introduction of batching should greatly improve performance when utilising write-behind cache stores, using putAll operations and committing transactions in non-transactional stores.

CacheWriter Interface Additions

The CacheWriter interface has been extended so that it exposes two additional methods: deleteBatch and writeBatch.  For the sake of backwards compatibility a default implementation of these methods is provided, however if your cache store is able to utilise batching we strongly recommend you create your  own implementations. The additional methods and docs are show below: 

Updated Stores

Currently the JDBC, JPA, RocksDB and Remote stores have all been modified to take advantage of these latest changes.

Configuration Changes

As each store implementations has different batching capabilities, it was necessary to introduce a max-batch-size attribute to the AbstractStoreConfiguration. This attribute defines the maximum number of entries that should be included in a single batch operation to the store. If a value less than one is provided, then the underlying store implementation should not place a upper limit on the number of entries in a batch. 

Deprecated Attributes

Both TableManipulationConfiguration#batchSize and JpaStoreConfiguration#batchSize have been deprecated, as they serve the same purpose as AbstractStoreConfiguration#maxBatchSize.

Store Benchmark

To measure the impact of batch writes on Cache.putAll, we created a simple benchmark to compare the performance of Infinispan 9.1.1.Final (with batching) and 9.0.3.Final (without).  The benchmark consisted of 20 threads inserting 100000 cache entries as fast as possible into a cache via putAll; with each putAll operation containing 20 cache entries and the max-batch-size of each store being set to 20. The table below shows the average time taken for each store type after the benchmark was executed three times.

Store Type	9.0.3.Final	9.1.1-Final	Latency Decrease
JdbcStringBasedStore	29368ms	2597ms	91.12%
JPAStore	30798ms	16640ms	45.97%
RocksDBStore	1164ms	209ms	82.04%

The benchmark results above clearly show that performance is increased dramatically when utilising batch updates at the store level.

Conclusions

Infinispan 9.1.x introduces batching capabilities to the CacheWriter interface in order to improve performance. If you currently utilise a custom cache store, we strongly recommend that you provide your own implementation of the delete and write batch methods. 

If you have any feedback on the CacheWriter changes, or would like to request some new features/optimisations, let us know via the forum, issue tracker or the #infinispan channel on Freenode.

Infinispan Cloud Cachestore 8.0.1.Final

After bringing the MongoDB up-to-date a few days ago, this time it's the turn of the Cloud Cache Store, our JClouds-based store which allows you to use any of the JClouds BlobStore providers to persist your cache data. This includes AWS S3, Google Cloud Storage, Azure Blob Storage and Rackspace Cloud Files.
In a perfect world this would have been 8.0.0.Final, but Sod's law rules, so I give you 8.0.1.Final instead :) So head on over to our store download page and try it out.

The actual configuration of the cachestore depends on the provider, so refer to the JClouds documentation. The following is a programmatic example using the "transient" provider:
 

And this is how you'd configure it declaratively:

This will work with any Infinispan 8.x release.

Enjoy !

MongoDB Cache Store 8.2.1.Final

In the storm of the persistence SPI rework that happened during Infinispan 6.0, the MongoDB cache store, among others, was left in a state of semi-abandonment for a long time.

Fortunately a few brave souls came to its rescue and have breathed new life into it so that it can be used with Infinispan 8.x

In particular I wish to thank Kurt Lehrke for doing most of the work !!!

Get it from the dedicated cache store download page.

The return of the Cassandra CacheStore

Ever since we spruced up our Cache Store SPI in Infinispan 6.0, some of our "extra" cache stores have lied in a state of semi-abandonment, waiting for a kind soul with time and determination to bring them back to life.
I'm glad to announce that such a kind soul, in the form of Jakub Markos, had the necessary qualities to accomplish the resurrection of the Cassandra Cache Store.

Apache Cassandra is a database with a distributed architecture which can be used to provide a virtually unlimited, horizontally scalable persistent store for Infinispan's caches. The new Cassandra Cache Store leverages the Datastax Cassandra client driver instead of the old Thrift client approach, which makes it much more robust and reliable.

Configuration

In order to use this cache store you need to add the following dependency to your project:
You will also need to create an appropriate keyspace on your Cassandra database, or configure the auto-create-keyspace to create it automatically.
The following CQL commands show how to configure the keyspace manually (using cqlsh for example):



You then need to add an appropriate cache declaration to your `infinispan.xml`
(or whichever file you use to configure Infinispan):

It is important the the shared property on the cassandra-store element is set to true
because all the Infinispan nodes will share the same Cassandra cluster.

Limitations

The cache store uses Cassandra's own expiration mechanisms (time to live = TTL) to handle expiration of entries. Since TTL is specified in seconds, expiration lifespan and maxIdle values are handled only with seconds-precision.

In addition to this, when both lifespan and maxIdle are used, entries in the cache store effectively behave as if their lifespan = maxIdle, due to an existing bug https://issues.jboss.org/browse/ISPN-3202.

So, try it out and let us know about your experience !

New Redis Cache Store Introduced in Infinispan 8

A new cache store for storage of cache data within the Redis key/value server has been introduced with Infinispan 8. This allows all storage of cache data to be stored in a centralised Redis deployment which all Infinispan clients access.

The cache store supports 3 Redis deployment topologies. They are, single server, Sentinel and cluster (Redis v3 required). Redis versions 2.8+ and 3.0+ are currently supported.

Data expiration and purging is handled via Redis itself, reducing workload from Infinispan servers to manually delete cache entries.

Topologies

Single Server

In a single server deployment, the cache store is given the location of a Redis master server with which it connects to directly to handle all data storage. Using this topology, Redis has no fault tolerance unless a custom solution is built on top of Redis. To declare a single server local cache store:

<?xml version="1.0" encoding="UTF-8"?>

<infinispan

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xsi:schemaLocation="urn:infinispan:config:8.0 http://www.infinispan.org/schemas/infinispan-config-8.0.xsd

                          urn:infinispan:config:store:redis:8.0 http://www.infinispan.org/schemas/infinispan-cachestore-redis-config-8.0.xsd"

    xmlns="urn:infinispan:config:8.0"

    xmlns:redis="urn:infinispan:config:store:redis:8.0" >

    <cache-container>

        <local-cache>

            <persistence passivation="false">

                <redis-store xmlns="urn:infinispan:config:store:redis:8.0"

                    topology="server" socket-timeout="10000" connection-timeout="10000">

                    <redis-server host="server1" />

                    <connection-pool min-idle="6" max-idle="10" max-total="20" min-evictable-idle-time="30000" time-between-eviction-runs="30000" />

                </redis-store>

            </persistence>

        </local-cache>

    </cache-container>

</infinispan>

Note the topology attribute is declared as server. This is needed to ensure a single server Redis topology is applied by the cache store. Only a single Redis server need be declared (only the first server will be used if multiple servers are declared) and the port will default to the Redis port 6379, but can be overridden using the port attribute. All connections are handled via a connection pool, which can optionally also test the validity of a connection on creation, lease, return from and when idling in the connection the pool.

Sentinel

The Sentinel topology relies on Redis Sentinel servers to connect to a Redis master server. Here, Infinispan connects to Redis Sentinel servers, requesting a master server name, then gets forwarded on to the correct location of the Redis master server. This topology gives resilience via Redis Sentinel, providing failure detection and automatic failover of Redis servers.

<?xml version="1.0" encoding="UTF-8"?>

<infinispan

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xsi:schemaLocation="urn:infinispan:config:8.0 http://www.infinispan.org/schemas/infinispan-config-8.0.xsd

                          urn:infinispan:config:store:redis:8.0 http://www.infinispan.org/schemas/infinispan-cachestore-redis-config-8.0.xsd"

    xmlns="urn:infinispan:config:8.0"

    xmlns:redis="urn:infinispan:config:store:redis:8.0" >

    <cache-container>

        <local-cache>

            <persistence passivation="false">

                <redis-store xmlns="urn:infinispan:config:store:redis:8.0"

                    topology="sentinel" master-name="mymaster" socket-timeout="10000" connection-timeout="10000">

                    <sentinel-server host="server1" />

                    <sentinel-server host="server2" />

                    <sentinel-server host="server3" />

                    <connection-pool min-idle="6" max-idle="10" max-total="20" min-evictable-idle-time="30000" time-between-eviction-runs="30000" />

                </redis-store>

            </persistence>

        </local-cache>

    </cache-container>

</infinispan>

For a Sentinel deployment, the topology attribute changes to sentinel. A master name must also be specified to select the correct Redis master required as Sentinel can monitor multiple Redis master servers. The Sentinel server is declared using a sentinel-server XML tag, which you’ll notice is different to the main Redis servers used in single server and cluster topologies. This is to allow defaulting of the Sentinel port to 26379 if not declared. At least one Sentinel server must be declared, though if you run more Sentinel servers, they should all be declared too for the benefit of failure detection of the Sentinel servers themselves.

Cluster

A cluster topology gives Infinispan the ability to connect to a Redis cluster. One or more cluster nodes are declared to infinispan (the more the better) which are then used to store all data. Redis cluster supports failure detection so if a master node in the cluster fails, a slave takes over. Redis v3 is required to run a Redis cluster.

<?xml version="1.0" encoding="UTF-8"?>

<infinispan

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xsi:schemaLocation="urn:infinispan:config:8.0 http://www.infinispan.org/schemas/infinispan-config-8.0.xsd

                          urn:infinispan:config:store:redis:8.0 http://www.infinispan.org/schemas/infinispan-cachestore-redis-config-8.0.xsd"

    xmlns="urn:infinispan:config:8.0"

    xmlns:redis="urn:infinispan:config:store:redis:8.0" >

    <cache-container>

        <local-cache>

            <persistence passivation="false">

                <redis-store xmlns="urn:infinispan:config:store:redis:8.0"

                    topology="cluster" socket-timeout="10000" connection-timeout="10000">

                    <redis-server host="server1" port="6379" />

                    <redis-server host="server2" port="6379" />

                    <redis-server host="server3" port="6379" />

                    <connection-pool min-idle="6" max-idle="10" max-total="20" min-evictable-idle-time="30000" time-between-eviction-runs="30000" />

                </redis-store>

            </persistence>

        </local-cache>

    </cache-container>

</infinispan>

For cluster deployments, the topology attribute must change to cluster. One or more Redis cluster nodes must be declared to access the cluster which uses the redis-server XML tag. Note that when operating a cluster, database IDs are not supported.

Multiple Cache Stores, Single Redis Deployment

Redis single server and Sentinel deployments support the option of database IDs. A database ID allows a single Redis server to host multiple individual databases, referenced via an integer ID number. This allows Infinispan to support multiple cache stores on the same Redis deployment, isolating the data between the stores. Redis cluster does not support the database ID. A database ID is defined using the database attribute on the redis-store XML tag.

<?xml version="1.0" encoding="UTF-8"?>

<infinispan

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xsi:schemaLocation="urn:infinispan:config:8.0 http://www.infinispan.org/schemas/infinispan-config-8.0.xsd

                          urn:infinispan:config:store:redis:8.0 http://www.infinispan.org/schemas/infinispan-cachestore-redis-config-8.0.xsd"

    xmlns="urn:infinispan:config:8.0"

    xmlns:redis="urn:infinispan:config:store:redis:8.0" >

    <cache-container>

        <local-cache>

            <persistence passivation="false">

                <redis-store xmlns="urn:infinispan:config:store:redis:8.0"

                    topology="sentinel" master-name="mymaster" socket-timeout="10000" connection-timeout="10000" database="5">

                    <sentinel-server host="server1" />

                    <sentinel-server host="server2" />

                    <sentinel-server host="server3" />

                    <connection-pool min-idle="6" max-idle="10" max-total="20" min-evictable-idle-time="30000" time-between-eviction-runs="30000" />

                </redis-store>

            </persistence>

        </local-cache>

    </cache-container>

</infinispan>

Redis Password Authentication

In order to secure access to a Redis server, a password can optionally be used in Redis. This then requires the cache store to declare the password when connecting. The password is added via a password attribute on the redis-store XML tag.

<?xml version="1.0" encoding="UTF-8"?>

<infinispan

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xsi:schemaLocation="urn:infinispan:config:8.0 http://www.infinispan.org/schemas/infinispan-config-8.0.xsd

                          urn:infinispan:config:store:redis:8.0 http://www.infinispan.org/schemas/infinispan-cachestore-redis-config-8.0.xsd"

    xmlns="urn:infinispan:config:8.0"

    xmlns:redis="urn:infinispan:config:store:redis:8.0" >

    <cache-container>

        <local-cache>

            <persistence passivation="false">

                <redis-store xmlns="urn:infinispan:config:store:redis:8.0"

                    topology="sentinel" master-name="mymaster" socket-timeout="10000" connection-timeout="10000" password="mysecret">

                    <sentinel-server host="server1" />

                    <sentinel-server host="server2" />

                    <sentinel-server host="server3" />

                    <connection-pool min-idle="6" max-idle="10" max-total="20" min-evictable-idle-time="30000" time-between-eviction-runs="30000" />

                </redis-store>

            </persistence>

        </local-cache>

    </cache-container>

</infinispan>

What about SSL support?

Redis does not provide protocol encryption, instead leaving this to other specialist software. At this time, the Redis client used to integrate Infinispan with Redis servers (Jedis) does not yet support SSL connection negotiation natively.

Infinispan 7.2.4.Final out including fixes for async store, Hot Rod...etc

Infinispan 7.2.4.Final is just out containing some important fixes in areas such as Hot Rod client and server, async cache store, key set iteration, as well as a Hibernate HQL parser upgrade. You can find more details about the issues fixed in our detailed release notes.

Happy hacking :)

Galder

Infinispan 6.0.0.Alpha4 out with new CacheLoader/CacheWriter API!

Infinispan 6.0.0.Alpha4 is now with a few very important changes, particularly around cache stores. We've completely revamped the cache store/loader API to align it a bit better with JSR-107 (old CacheStore has become CacheWriter) and to simplify creation of new implementations. The new CacheLoader and CacheWriter should help implementors focus on the important operations and reduce the coding time. We've also created AdvancedCacheLoader and AdvancedCacheWriter in order to separate for bulk operations or purging for those implementations that wish optionally implement them. Expect a blog post from Mircea in the next few days providing many more details on this topic.

This new Infinispan version comes with other important goodies:

• Rolling upgrades of a Infinsipan REST cluster
• Support for Cache-Control headers for REST operations
• Remote querying server modules and Hot Rod client update
• REST and LevelDB stores added to Infinispan Server
• KeyFilters can now be applied to Cache listeners
• Allow Cache listener events to be invoked only on the primary data owner

For a complete list of features and fixes included in this release please refer to the release notes. Visit our downloads section to find the latest release and if you have any questions please check our forums, our mailing lists or ping us directly on IRC.

Cheers,

Galder

Using MongoDB as a cache store

With the 5.3 release, there is a brand new feature. I'm glad to announce that you will be able to use MongoDB as a cache store.

For those who don't know MongoDB, it's an open-source document oriented NoSQL database developped by 10Gen. You can more information about it on http://www.mongodb.org/.

The question you have right now, it probably, how to use it cool cache store ? Simple, as for the other cache store you have to add a loader in your Infinispan configuration file.

Here is an exemple:

If you prefer the programmatic API:
For more information about the configuration possibilities (default values, options, etc) , you can refer to the documentation page

Cheers,
Guillaume
Hibernate OGM & Infinispan contributor
Blog / @g_scheibel

Introducing JPA Cache Store

Good news everyone - Infinispan 5.3.0 will be introducing a long awaited JPA cache store.  This cache store will allow you to store cache entries in the database using proper schema - so that other applications can read the persisted data as well.

In normal use cases, it's recommended to leverage Infinispan as JPA second level cache and/or query cache. However, if you'd like to use only Infinispan API and you want Infinispan to read from database, or to persist the data into a database with well defined schema, then JPA cache store could be right for you.

Prior to JPA cache store, those who wants to use Infinispan in front of a database to read/write database records would need to write their own cache store implementation.  Now, with JPA cache store, users can use Infinispan in front of a database (write-through or write-behind) with ease by using standard JPA mapping and configurations.

To use the cache store is simple - create the standard JPA configuration (persistence.xml) and entity class, and then configure the cache store:

Please see documentations for detailed sample usage and configuration.

Hope you enjoy this new addition!

Ray

Configuration overhaul

Infinispan 5.2 will sport a much needed configuration overhaul which will affect both the programmatic builder API and the declarative XML parsing.

As you all know by now, 5.1 introduced a new fluent builder-based API with immutable POJOs for configuring Infinispan's core. This coolness however was not extended to all the extra modules available for Infinispan (and there are quite a few of those), leaving them with a simple untyped key/value properties-based configuration. This was especially visible (and painful) when configuring the cache loaders, some of which have a plethora of parameters and options.

In 5.2 modules become first-class citizens and can provide their own builders and can take care of parsing their own XML for which they can provide a custom schema (for editors/IDE which provide content-assist). Modules can retrieve information from either the GlobalConfiguration or the per-cache Configuration objects via the T modules(Class<T> moduleClass) method.

Loaders and Stores also get this treatment. Look at the two before and after configurations below for configuring the JDBC Cache Store.

Before:

After:

You will be able to check-out these features in Infinispan 5.2.0.Alpha3. Bear in mind that at the time of writing not all cache loaders have been migrated to this new configuration style, but they should all be complete by the time 5.2.0.Final is released.

If you want to learn how to extend Infinispan's configuration for your own modules, head over to ExtendingInfinispansConfiguration which should provide all the information you need

Infinispan 5.2.0.ALPHA2 is here!

Infinispan 5.2.0.ALPHA2 was released last Friday with several additions for those that like to test Infinispan's bleeding edge capabilities. In this case, it's out Map/Reduce functionality that's the star of the show:

• A combiner can now be used between the Map and Reduce phases
• Reduce phase can now be distributed
• Map/Reduce now processes entries in cache stores too

Vladimir Blagojevic, one of our Infinispan developers, will be explaining all about these features in a blog post coming right up, so stay tuned! :)

Finally Adrian Nistor, the latest addition to the Infinispan team, has been working on reducing the size of our distribution files by avoiding duplication of jars.

Cheers,

Galder

Infinispan 5.1.5 goes FINAL!

Infinispan 'Brahma' 5.1.5.FINAL has now been released fixing a whole bunch of issues around cache store preloading of distributed caches, Memcached server, tree module and Hot Rod client performance. We've also updated several libraries such as Netty (to 3.4.6) and JGroups (to 3.0.10).

Full details of what has been fixed can be found here, and if you have feedback, please visit our forums. Finally, as always, you can download the release from here.

Cheers,
Galder

How to configure Infinispan with transactions, backed by relational DB on JBoss AS 7 vs. Tomcat 7

Migrating projects from one container to another is often problematic. Not as much with Infinispan. This article is about configuring Infinispan, using Transaction Manager for demarcating transaction boundaries, while keeping the data both in a memory and relational database - stored via JDBC cache store. I'll demonstrate all the features on code snippets. 

A complete application is located at https://github.com/mgencur/infinispan-examples and is called carmart-tx-jdbc. It's a web application based on JSF 2, Seam 3 and Infinispan 5.1.4.FINAL, is fully working, tested with JBoss  Application Server 7.1.1.Final and Tomcat 7.0.27. There  is one prerequisite, though. It needs an installed and working MySQL database in your system. The database name should be carmartdb, accessible by a user with carmart/carmart username/password.
 
First, look at what we need to configure for JBoss Application Server 7. 

Configuring transactions and JDBC cache store on JBoss AS 7

Infinispan will be configured via new fluent API using builders, hence the call to  .build() method at the end. We need to configure aspects related to  transactions and cache loaders. The configuration API for cache loaders  is likely going to be changed in not-so-far future. It should be fluent  and more intuitive, generally easier to use than current one. 

I purposely do not show XML configuration. Configuration examples can be found at https://github.com/infinispan/infinispan/blob/master/core/src/main/resources/config-samples/sample.xml. In order to configure transactions and cache loaders, look for tags called  <transaction> and <loaders> and modify that sample file according to below configuration. Tag names and attribute names are very similar for both XML and Java configuration. If that is not enough, there is always a schema in Infinispan distribution.

The configuration of Infinispan is as follows: 


Lines marked with red are different in other containers/configurations, as you'll see in a minute. The code above implies that we need to specify proper TransactionManagerLookup implementation which is, in this case, GenericTransactionManagerLookup. We  also need to say: "Hey, I wanna use ManagedConnectionFactory as a connectionFactoryClass". OK, here we go. I should, as well, explain how to configure a datasource properly, right? In JBoss AS 7, this is configured as a subsystem in $JBOSS_HOME/standalone/configuration/standalone.xml:


The usage of transactions is very simple as we can obtain a transaction object by injection.


Sources: https://github.com/mgencur/infinispan-examples/blob/master/carmart-tx-jdbc/src/jbossas/java/org/infinispan/examples/carmart/session/CarManager.java

Quite easy, isn't it ...if you know how to do it. The only problem is that it does not work (at least not completely) :-) If you deploy the app, you find out that when storing a key-value pair in  the cache, an exception is thrown. This exception indicates that the operation with DB (and JDBC cache store) failed. The exception says:


A complete stack trace looks similar to https://gist.github.com/2777348
There's still an open issue in JIRA (ISPN-604) and it is being worked on. 

Configuring transactions and JDBC cache store on JBoss AS 7 - c3p0

But how do we cope with this inconvenience for now... By not using a managed datasource but rather a third party library called c3p0 (JDBC3  Connection and Statement Pooling, more information at http://www.mchange.com/projects/c3p0/index.html) Infinispan allows you to use this library for connecting to the database. If you really want to use it, you need to choose a different connectionFactoryClass which is, in this case, PooledConnectionFactory.

Infinispan configuration looks like this:

Transactions are accessible in the same way as in the previous use case. Now let's look at configuration for Tomcat servlet container. 

Configuring transactions and JDBC cache store on Tomcat 7

Tomcat does not have any Transaction Manager in it so we have to bundle one with the application. For the purpose of this exercise, we choose JBoss Transactions (http://www.jboss.org/jbosstm). See dependencies at the end.

Cache manager and cache configuration is in this form:


For Tomcat, we need to specify a different transactionManagerLookup implementation and datasourceJndiLocation. Tomcat simply places objects  under a bit different JNDI locations. The datasource is defined in context.xml file which has to be on classpath. This file might look like this:


How do we get the transaction manager in the application then? Lets obtain  it directly from a cache. 

Infinispan knows how to find the manager and we need to know how to obtain it from Infinispan.


Sources: https://github.com/mgencur/infinispan-examples/blob/master/carmart-tx-jdbc/src/tomcat/java/org/infinispan/examples/carmart/session/CarManager.java The transaction manager provides standard methods for transactions, such as begin(), commit() and rollback(). 

Now is the time for dependencies

So...which dependencies do we always need when using Infinispan with JDBC cache stores and transactions? These are infinspan-core, infinispan-cachestore-jdbc and javax.transaction.jta. The scope for jta dependency, as defined in Maven, is different for JBossAS and Tomcat.

Common dependencies for JBossAS and Tomcat


Of course, our application needs a few more dependencies but these are not directly related to Infinispan. Let's ignore them in this article. JBoss AS 7 provides managed datasource that is accessible from Infinispan. The only specific dependency (related to transactions or Infinispan) is JTA.

Dependencies specific to JBossAS - using managed Datasource (managed by the server)


Dependencies specific to JBossAS - using c3p0


Yes, you need to bundle also MySQL connector. On the other hand, for Tomcat use case and JBossAS with managed datasource, this jar file needs do be deployed to the server separately. For Tomcat, do this simply by copying the jar file to $TOMCAT_HOME/lib.  For JBoss AS 7, copy the jar file into $JBOSS_HOME/standalone/deployments.

Dependencies specific to Tomcat - using JBoss Transactions


That's it. I hope you've found this article helpful. Any feedback is welcome, especially the positive one :-) If you find any problem with the  application, feel free to comment here or participate in Infinispan forums (http://www.jboss.org/infinispan/forums).

Martin