Concurrent upgrade from a read-lock to a write-lock by *diff

[youngm]

I noticed in the changelog for 1.2.1 the following note:

* Concurrent upgrade from a read-lock to a write-lock by *different* transactions on the *same* node is currently not
supported, e.g. get("/a/b/c") acquires a RL, subsequent put("/a/b/c") by the same transaction will acquire a write
lock. If multiple transactions try to simultaneously upgrade "/a/b/c" from RL to WL, only one will succeed, the others
will get an exception (and therefore roll back their transaction):
UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock)


Is there an ETA for support for concurrent upgrade from a read-lock to a write-lock by *different* transactions on the *same* node? I'm attempting to use JBossCache as both a distributed cache and a distributed transactional lock for some data that is both being accessed by different nodes and different threads in the same node. This one issue is created a huge problem for my plan.

I'm sure that there is something going on making this more difficult than it seems but it would seem that if you can have Concurrent upgrades for different transactions in different nodes then support for upgrading different transactions in the same node would be easy.

Mike

[belaban]

There is no ETA yet, especially because I wanted to use the util.concurrent ReentrantWriterPrefLock, but IMO it exposes incorrect semantics wrt upgrading. There is a unit test in JBossCache that demos the problem.

[youngm]

So....does that mean that I should look elsewhere for a distributed transactional locking mechanism if I think multiple readers requesting upgrade is going to be frequent?

Mike

[ben.wang]

Key is multiple readers requesting the *same* node upgrade. In general, this is not that frequent since cache by first assumption should be read mostly anway.

-Ben

[youngm]

Key is multiple readers requesting the *same* node upgrade.

This is true. Perhaps my problem is I'm not necissarily using JBossCache in what would be though of as a normal cache type of scenario. Instead I'm trying to use JBossCache as more of a distributed object store. I have a large group of objects which are very expensive to build and are modified fairly frequently being shared throughout my cluster reading is taking place far more often than writing but concurrent writing is still something that happens fairly often. So, I figured I could use JbossCache to distribute the object and manage the transactional locking for me.

JBossCache is working perfectly for me in this goal with the exception of this one problem. I'm getting UpgradeExceptions far more often then desired.

Mike

[belaban]

Here's the JIRA issue: http://jira.jboss.com/jira/browse/JBCACHE-97.

You can vote on it. More votes means we bump up the priority...

[youngm]

You can vote on it. More votes means we bump up the priority...

It appears that issue is now the most popular one. :) I hope that helps.

http://jira.jboss.com/jira/browse/JBCACHE?report=com.atlassian.jira.plugin.system.project:popularissues-panel

I'm just joking with you. I understand that me and the other guy who voted are only two user and there are probably plenty of more pressing issues on your plate. I'd come up with a solution myself but I'm not smart enough and begger's can be choosers so I'll be watching the issue with great antisipation.

Thanks for the hard work you all put into this project.

Mike

[ben.wang]

I guess I don't quite get your access pattern then.

Can you have dedicated writer threads such that you don't do upgrade lock. Multiple writers can still wait. The restriction is only when you have multiple simultaneous upgrade lock that will throw exception.

Or, the other option is change the isolation level.

-Ben

[youngm]

Maybe I should just explain my scenario. :)

Basically I have a tree of accounts who can credit, debit, and view their account balances. They credit and debit by adding an item to their transaction log. Each account balance also has a limit. So debits need to be monitored carefully to ensure the account is not going over it's limit.

I'm creating a balance cache for each account that contains the current balance of an account by summing up the accounts transaction log. This cache is used to help speed up viewing of acount balance (which happens every time the user loads a page) and to speed up debiting of the account balance by allowing for a fast limit check.

When a transaction is added to the log I lock the balance cache object and make the adjustments to the cache accordingly instead of recreating the balance cache everytime the balance changes. Debits can occationally happen very frequently accross many threads throughout the cluster through scheduled events and such.

I don't think the UpgradeException would cause a problem under the above scenario. Where things get bad is that when an account debits from their own account a debit (depending upon the type of debit) a debit will also happen to the account's parent account and so on all the way to the root of the tree accross the cluster.

So, the further up the tree I go, the larger the account tree, and the more frequent the debits the more UpgradeExceptions I'm get.

Does that explanation help? I'm I dumb to be using JBossCache in such a way? :)

Multiple writers can still wait. The restriction is only when you have multiple simultaneous upgrade lock that will throw exception.

This comment caught my eye. Is it possible to obtain a write lock for an object without first obtaining a read lock? I didn't know that was possible perhaps that can help my situation.

Mike