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?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133007#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...