How does EHCache implement its transactions?

Question

Hi, The question might sound vague but I'm trying to understand the general concept of the EHCache transaction ability.
Assuming I configure EHCache as a memory cache and I also configure it to cache a MyObject.
Does EHCache clone the instance of MyObject I'm retrieving if this is done as a part of a transaction?

I'm mainly asking because I was advised (in the answer to my question) to use EHCache and I'm worried about its performance impact. MyObject is a medium-weight object and I'd rather not duplicate it unneccesarily.
Also, just to verify, EHCache only blocks writing to the object while in transaction, right?

Thanks,
Ittai

Answer 1

I think the following part of the documentation about the JTA support answers most of your questions:

Using a JTA Cache

All or nothing

If a cache is enabled for JTA all operations on it must happen within a transaction context, otherwise a TransactionRequiredException will be thrown.

Change Visibility

The isolation level offered in Ehcache JTA is READ_COMMITTED. Ehcache is an XAResource. Full two-phase commit is supported.

Specifically:

• All mutating changes to the cache are transactional including put, remove, putWithWriter, removeWithWriter and removeAll.
• Mutating changes are not visible in the local JVM to or across the cluster until COMMIT has been called.
• Until then, read such as by cache.get(...) by other transactions will return the old copy. Reads do not block.

Write-behind and Write-through

If your XA enabled cache is being used with a writer, write operations will be queued until transaction commit time. Solely a Write-through approach would have its potential XAResource participate in the same transaction. Write-behind, while supported, should probably not be used with an XA transactional Cache, as the operations would never be part of the same transaction. Your writer would also be responsible for obtaining a new transaction...

Using Write-through with a non XA resource would also work, but there is no guarantee the transaction will succeed after the write operation have been executed successfully. On the other hand, any thrown exception during these write operations would cause the transaction to be rolled back by having UserTransaction.commit() throw a RollbackException.

Regarding performances, I wouldn't worry too much unless your object weights hundreds MB. But if this is really a concern, measure things (as always).