How have you configured Wildfly 8 to use Infinispan for caching entities?

[zds]

Hello!

As I'm running into brick wall with trying to find a way to use Infinispan as second level cache with Wildfly 8, I'm turning to you. If you are using Wildfly (or JBoss 7) and caching entities with Infinispan, how do you do it?

Here's how I do it, but considering how simple operations cause Wildfly/Infinispan to fail, there must be something wrong here:

1) persistence.xml looks like this:

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

<persistence xmlns="http://java.sun.com/xml/ns/persistence"

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

    xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"

    version="2.0">

  <persistence-unit name="k3_operational_persistence" transaction-type="JTA">

     <jta-data-source>DATASOURCE_NAME</jta-data-source>

     <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>

  <properties>

     <property name="hibernate.hbm2ddl.auto" value="validate"/>

     <property name="hibernate.cache.use_second_level_cache" value="true"/>

     <property name="hibernate.cache.use_query_cache" value="true"/>

     <property name="hibernate.generate_statistics" value="true" />

  </properties>

  </persistence-unit>

</persistence>

And then, 2) on selected beans I have annotated the bean like this:

import org.hibernate.annotations.Cache;

import org.hibernate.annotations.CacheConcurrencyStrategy;

@Entity()

@Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)

public class SampleEntity {

So the question is: If you got it working, how did you set it up? Or: what's wrong with my configuration?

[lafr]

Use JPA 2.0 standard annotation javax.persistence.Cacheable(true) instead.

That should work.

[zds]

Unfortunately, at least on the bug reproduction test case I have at hand, it made no difference if it was hibernate or javax annotation that was used; if I ask Infinispan to be a 2LC, I get into trouble.

[smarlow]

As Frank suggested, instead of using the org.hibernate.annotations.Cache (@Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)), use the javax.persistence.Cacheable annotation.

Here is an example (from the WildFly 8 testsuite) that shows an example entity that is tagged with the javax.persistence.Cacheable annotation.  https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/Employee.java.

Can you describe what you are observing in greater detail.  Are you reading the 2lc statistics via the web management console or perhaps via jboss-cli tool?

Are you using WildFly 8.0.0.Beta1?  If yes, you can also enable JPA trace logging which will log one of the following that will help you know if the cache was enabled:

JPA_LOGGER.tracef("second level cache enabled for %s", pu.getScopedPersistenceUnitName());

or

JPA_LOGGER.tracef("second level cache disabled for %s, pu %s property = %s, pu.getSharedCacheMode = %s",
        pu.getScopedPersistenceUnitName(),
        SHARED_CACHE_MODE,
        sharedCacheMode,
        pu.getSharedCacheMode().toString());

If that isn't enough of a clue, describe the symptoms around the trouble that you are experiencing, in greater detail.

Scott

[zds]

I'm not seeing the "second level cache enabled/disabled" printout, but it's the infinispan part that throws the exception, and if I comment out the @Cacheable (or @Cache, it does not matter which one I use), my test case works.

Logging from the deployment time of my test case shows this:

2013-10-10 10:22:59,566 DEBUG [org.hibernate.jpa.internal.util.LogHelper] (ServerService Thread Pool -- 52:) PersistenceUnitInfo [

        name: persistence_context2

        persistence provider classname: org.hibernate.jpa.HibernatePersistenceProvider

        classloader: ModuleClassLoader for Module "deployment.infinispan_bug_reproduction2.war:main" from Service Module Loader

        excludeUnlistedClasses: false

        JTA datasource: org.jboss.jca.adapters.jdbc.WrapperDataSource@5330759

        Non JTA datasource: null

        Transaction type: JTA

        PU root URL: vfs:/content/infinispan_bug_reproduction2.war/WEB-INF/classes/

        Shared Cache Mode: ENABLE_SELECTIVE

        Validation Mode: AUTO

        Jar files URLs []

        Managed classes names []

        Mapping files names []

        Properties [

                hibernate.cache.infinispan.container: hibernate

                hibernate.generate_statistics: true

                hibernate.cache.region_prefix: infinispan_bug_reproduction2.war#persistence_context2

                hibernate.cache.use_second_level_cache: true

                hibernate.cache.region.factory_class: org.jboss.as.jpa.hibernate4.infinispan.SharedInfinispanRegionFactory

                hibernate.hbm2ddl.auto: update]

I also see the Infinispan initializing when the .war containing my test case is deployed.

I created a bug report to Wildfly issue tracking about this: [WFLY-2267] Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage. - JBoss Issue Track…

The purpose of this discussion thread was to figure out if there was a different way of configuring the Infinispan, a one that would avoid running in the bug I reported.

[smarlow]

I haven't dug into the details of the WFLY-2267 jira yet but am curious what happens if you update the wf8/standalone/configuration/standalone.xml Infinispan configuration use a non-transactional entity cache instead of transactional.  In summary, you are changing the entity cache from using transaction mode of NON_XA to NONE.  Change from:

<subsystem xmlns="urn:jboss:domain:infinispan:2.0">

    <cache-container name="web" aliases="standard-session-cache" default-cache="local-web" module="org.wildfly.clustering.web.infinispan">

        <local-cache name="local-web" batching="true">

            <file-store passivation="false" purge="false"/>

        </local-cache>

    </cache-container>

    <cache-container name="hibernate" default-cache="local-query" module="org.hibernate">

        <local-cache name="entity">

            <transaction mode="NON_XA"/>

            <eviction strategy="LRU" max-entries="10000"/>

            <expiration max-idle="100000"/>

        </local-cache>

        <local-cache name="local-query">

            <transaction mode="NONE"/>

            <eviction strategy="LRU" max-entries="10000"/>

            <expiration max-idle="100000"/>

        </local-cache>

        <local-cache name="timestamps">

            <transaction mode="NONE"/>

            <eviction strategy="NONE"/>

        </local-cache>

    </cache-container>

</subsystem>

To:

<subsystem xmlns="urn:jboss:domain:infinispan:2.0">

    <cache-container name="web" aliases="standard-session-cache" default-cache="local-web" module="org.wildfly.clustering.web.infinispan">

        <local-cache name="local-web" batching="true">

            <file-store passivation="false" purge="false"/>

        </local-cache>

    </cache-container>

    <cache-container name="hibernate" default-cache="local-query" module="org.hibernate">

        <local-cache name="entity">

            <transaction mode="NONE"/>

            <eviction strategy="LRU" max-entries="10000"/>

            <expiration max-idle="100000"/>

        </local-cache>

        <local-cache name="local-query">

            <transaction mode="NONE"/>

            <eviction strategy="LRU" max-entries="10000"/>

            <expiration max-idle="100000"/>

        </local-cache>

        <local-cache name="timestamps">

            <transaction mode="NONE"/>

            <eviction strategy="NONE"/>

        </local-cache>

    </cache-container>

</subsystem>

This is just a guess due to a problem I recently saw with Cache.evictAll().  Knowing whether the above configuration change helps or not, will be interesting to know. 

[zds]

A clever suggestion! Changing the <transaction mode="FULL_XA"/> to <transaction mode="NONE"/> indeed makes the problem go away.

[zds]

And indeed, even with NON_XA the bug stays hidden. So thanks, using FULL_XA was what took our setup into "not everyone does it like this" territory and exposed to bugs.