-
1. Re: Concurrent upgrade from a read-lock to a write-lock by *
belaban Apr 27, 2005 6:07 PM (in response to youngm)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.
-
2. Re: Concurrent upgrade from a read-lock to a write-lock by *
youngm Apr 27, 2005 6:46 PM (in response to 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 -
3. Re: Concurrent upgrade from a read-lock to a write-lock by *
ben.wang Apr 27, 2005 9:46 PM (in response to youngm)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 -
4. Re: Concurrent upgrade from a read-lock to a write-lock by *
youngm Apr 27, 2005 10:14 PM (in response to 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 -
5. Re: Concurrent upgrade from a read-lock to a write-lock by *
belaban Apr 28, 2005 2:41 AM (in response to youngm)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... -
6. Re: Concurrent upgrade from a read-lock to a write-lock by *
youngm Apr 28, 2005 12:40 PM (in response to 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 -
7. Re: Concurrent upgrade from a read-lock to a write-lock by *
ben.wang Apr 28, 2005 1:10 PM (in response to youngm)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 -
8. Re: Concurrent upgrade from a read-lock to a write-lock by *
youngm Apr 28, 2005 1:42 PM (in response to 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