• New Feature
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • kkannaiy
  • Reporter: alexsnaps
  • March 30, 2010
  • 0
  • Watchers: 0
  • January 17, 2013
  • April 07, 2010


In order to support JTA in standalone Ehcache, the CompoundStore now supports copyOnRead & copyOnWrite. Should these be added to the config file for people to use without using JTA? Also, the actually copy uses a pluggable strategy. So that people could use different approach to copying Element (e.g. clone vs. the default serialization one). This should also be added to the configuration, e.g. copyStategyClass=”FQCN” (or should it only be set through a system prop, to keep it more hidden from the user?)… With that in mind, I thought the naming all these 3 configuration options should be evaluated.


Steve Harris 2010-03-30

Work with greg to figure out what the config might look like and see if we can get it in.

gluck 2010-03-30

Firstly JTA

We have right now:

transactionalMode=”xa”, otherwise the default is transactionalMode=”off”

Do we keep using xa for standalone Ehcache?

I had a read of http://static.springsource.org/spring/docs/2.0.x/reference/transaction.html and several other sources. To me it seems that in standalone the cache is a single resource rather than being clustered, but the transaction could still involve multiple network resources such as two databases, so I am not seeing why this would not stay as “xa”.

Secondly copy semantics.

Using copy is useful if you want to ensure that threads using the same cache Elements cannot interfere with each other. So instead of holding a reference to the same object, each thread gets its own. Similarly when an object is put in a cache. by copying on put, any changes made to the Element after the put are not reflected in the cache.

While potentially useful, copy on x has a cost in both increased latency, CPU and memory use. For that reason it should not be the default and needs to be explicitly configured to take effect.

Following is my suggestion. copyOnRead and copyOnWrite. Bot are both optional.

The <terracotta …> element also has copyOnRead. We should honour it for backward compatibility but remove it from the schema and examples now that that setting has migrated to be a cache attribute.

If JTA is set to “xa” and either copyOnRead or copyOnWrite is set to false, then an InvalidConfigurationException should be thrown.

The pluggable copy strategy I guess is simple enough to just need a class rather than using the abstract factory pattern with properties passed in. So it could be declared as:

Alexander Snaps 2010-04-07

r21612 for tim-ehcache on forge, trunk (r21613 on tc-3.2 branch)

Kalai Kannaiyan 2010-05-06

Verified with 3.2.1_2 kit and ehcache 2.1.0 kit, copyOnRead and copyOnWrite options are added with default=false in the ehcache.xsd and ehcache.xml supports as expected.