Patch adding transactional putSilent() method

[cyberax]

Please, can you review this patch for addition into the mainline JBoss Cache?

The motivation for this patch

Currently, JBoss Cache adapter for Hibernate uses putForExternalRead() method. This method suspends and then resumes the current transaction and this is slow with some transaction managers, particularly with ones that support transaction recovery. For example, with Atomikos Transaction Manager it takes 25 seconds with putForExternalRead() on my computer to load a big Hibernate model versus 3 seconds with simple put() method in org.hibernate.cache.Cache implementation.

But simple put() method can't be used reliably, because DataVersioningException will be thrown if another thread has loaded the same object and put it in the cache.

Patch details

I've developed this patch to solve this problem. It adds putSilently() method to Cache interface, this method works exactly like putForExternalRead() except that it does not suspend and resume the current transaction. Instead, workspace nodes are marked so they can be ignored during optimistic validation if it fails.

I don't have much experience with JBoss Cache, but this patch works for me (or at least looks like it is working :) ). If the general idea is OK, I'll add mode documentation and unit tests for inclusion into the official JBoss Cache package.

You can get the patch here: http://sd-sup.staffdirector.net/cache.patch

PS: this is a crosspost from JBoss Cache user forum.

[manik]

Thanks for this, will review and get back to you

[manik]

Just an initial thought on your patch, but by not suspending any ongoing transactions and working on the workspace nodes directly means that this fix isn't portable across node locking schemes. In the pessimistic case this will still allow cache failures to cause your business transactions to roll back.

[cyberax]

Just an initial thought on your patch, but by not suspending any ongoing transactions and working on the workspace nodes directly means that this fix isn't portable across node locking schemes. In the pessimistic case this will still allow cache failures to cause your business transactions to roll back.

Yes, I know. I was not interested in pessimistic locking when I wrote this patch.

Please, correct me if I'm wrong, I think that we can just discard exceptions from put() method in pessimistic locking mode.

[manik]

I realise you're not interested in pessimistic locking, but any optimisation needs to be generic enough to work across both schemes. :-)

Not if this is within a tx. This could cause the whole tx to rollback.

[cyberax]

I realise you're not interested in pessimistic locking, but any optimisation needs to be generic enough to work across both schemes. :-)

I'll try to generify my optimization :)

Not if this is within a tx. This could cause the whole tx to rollback.

As far as I understand by reading PessimisticLockInterceptor, rollback is caused by UpgradeException/TimeoutException/... propagating through the stack. So the easiest solution is to ignore these exceptions for putSilent() nodes. Am I correct?