Link: Added: This issue Cloned to SOA-3152

Link: Removed: This issue Cloned to SOA-3152 

Link: Added: This issue is related to JBPM-3281

Link: Added: This issue Cloned to JBPM-3281

Link: Removed: This issue is related to JBPM-3281 

Link: Removed: This issue Cloned to JBPM-3281 

Link: Added: This issue incorporates JBPM-3281

Link: Removed: This issue incorporates JBPM-3281 

This configuration is provided by the platform integration so should be handled by someone from the platform team.

The short answer is: with regards to the that particular file, we only need to _add_ the lines specified above (hibernate properties).
But at the moment, there are some things that don't make sense to me. 

As of Hibernate-Caching 3.3, the default configuration for the hibernate mechanism that supports jBoss Cache in a clustered environment is such that it defaults to optimistic locking: the property in question is "{{hibernate.cache.region.jbc2.cfg.entity}}": ([3.3 doc|http://docs.jboss.org/jbossclustering/hibernate-caching/3.3/en-US/html_single/#sessionfactory-multiplexed]). In 3.5, it's been updated to MVCC ([3.5 doc|http://docs.jboss.org/jbossclustering/hibernate-caching/3.5/en-US/html_single/#sessionfactory-multiplexed]). 

I'm guessing that SOA 5.2.0  will still depend on Hibernate-Caching 3.3 (or less)? Otherwise, it doesn't seem like this would be necessary, given that Hibernate-Caching 3.5 has MVCC as the default. 

By adding the lines above, we're ensuring that hibernate-caching runs in a clustered environment with the MVCC as the default locking scheme. This will then support the jBoss Cache MVCC mechanism the way it wants to be supported (I think?). 

----

But, what I don't understand is that while we're modifying the hibernate properties, there's still the jBoss Cache (and *it's* configuration) on top of that:
{noformat}
---------------------
| Application (jBPM)|
---------------------
| jBoss Cache       |
---------------------
| Hibernate-Caching |
---------------------
| Database          |
---------------------
{noformat}

*Configuration*:
See [here|http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/5/html-single/JBoss_Cache_User_Guide/index.html#deployment.microcontainer] for an example -- in the xml there (scroll down a bit), you could add 

{{<attribute name="NodeLockingScheme">OPTIMISTIC</attribute>}}

to the config, and it would be optimistically locked. [The most recent documentation about optimistic (cache) node locking configuration is [here (old documentation)|http://docs.jboss.org/jbosscache/2.1.1.GA/userguide_en/html_single/index.html#d0e3708]
(scroll down to 10.1.3.3. Configuration).]

There is indeed a jBoss cache configuration file in the distribution module of jbpm: 
http://anonsvn.jboss.org/repos/jbpm/jbpm3/branches/jbpm-3.2-soa/distribution/src/main/resources/cache/jbpm-jbc-service.xml

*Old version of jBoss Cache:*
This file ({{jbpm-jbc-service.xml}}) -- of course -- does exactly what I outline above and sets NodeLockingScheme to Optimistic. Furthermore, it's not possible to use MVCC because we're using the (jBoss Cache) TreeCache object, which 1) doesn't have other NodeLockingScheme's besides Optimistic and  Pessimistic and 2) is discontinued after jBoss Cache 1.4.1 (<-> jBoss AS 4.0.5]
(See this [compatibility matrix|http://www.jboss.org/jbosscache/compatibility.html] for jBoss Cache <-> AS info). 

Of course, we're using this version of jBoss Cache because it's what dictated to us by the hibernate-jbc-cache dependency in distribution/pom.xml. We can not update the version of hibernate-jbc-cache in order to fix this, because we're already using the last version. 

*Possible fix:*
- It seems like it would also be necessary (or advisable) to update the jBPM jBoss Cache config so that it uses a Pojo Cache. 
- Obviously, that would also mean that we would update dependencies so that jBoss Cache 3.0.1 would be used instead of 1.4.1.
- Lastly, there are also possibly other dependencies that need to be updated, seeing as we would no longer use the hibernate-jbc-cache dependency (which limits us to jboss cache 1.4.1), but roll our own set. 

----

*Conclusion*
Most of the stuff above is for documentation purposes, should this come up again. 

At the time being, given that Martin knows what he's doing (and is unfortunately on vacation), we'll just go with adding those two lines. (It seems to already have been shown that just adding those two lines is enough to make things work.)

Verified in ER4