locking & CacheSPI

[nnnnn]

We have a need (we think - unless somebody has a better suggestion) to try to do lock nodes in some situations.

When our application decides to write to the cache, it needs to check what's already at the node that's there, and then depending on what it finds, it may choose to put the new object in the cache in the same node, or it may decide not to. It's important that a different thread doesn't change the object at that key in that node in between the read and the write. Locking behavior is what we want - the other thread should wait until the first thread is done before writing.

Sounds like we want to get a read lock for the read, and then promote it to a write lock for the write. However, if there are other suggestions on how to do this, I'm all ears.

So the problems:
- the decision on whether to write is application logic. The object stored is an application object. I really don't think that extending the PessimisticLockInterceptor is the right way to do this, because of the application logic that goes on in between the read and the write.
- There's no "accepted" way for the application sitting on top of JbossCache to get a CacheSPI object (and thus be able to acquire its own locks).
- If I were to get a CacheSPI object, what do I have to do to ensure that the object that I use to lock the node is the same object that the PessimisticLockInterceptor uses to lock it (so that it can acquire the lock when I actually do the write)?

Ideas?

[mircea.markus]

When our application decides to write to the cache, it needs to check what's already at the node that's there, and then depending on what it finds, it may choose to put the new object in the cache in the same node, or it may decide not to. It's important that a different thread doesn't change the object at that key in that node in between the read and the write. Locking behavior is what we want - the other thread should wait until the first thread is done before writing.

you should open a transaction (REPETABLE_READ) which would only commit after the write. This will assure that the read data won't be modified by other thread until commit/rollback takes place.

[nnnnn]

Right, that's what I would like to do. But how do I do that from application code without having my app code operate in an Interceptor? Am I missing something easy?

[manik]

Use a Transaction Manager (see the user guide for how to configure one) and start a user transaction before your cache operations (reads, writes). And then commit your transaction. The cache will participate in the transaction and treat all operations as scoped to the same ongoing transaction.