[jboss-user] [JBossCache] - locking & CacheSPI

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...