Yes, this is on the todo list. There is a JIRA issue *and* a testcase (which fails). I want to use the util.concurrent WriterPreferredReaderWriteLock (or whatever it is called), to do this, but it's broken. Take a look at the unit test, it shows who (IMO) is broken with it. We should contact the util.concurrent folks at some time and get a clarification.
This case only happens when multiple threads hold locks on the *same* FQN, and everybody tries to upgrade to a write lock at the same time
The problem with this issue is there is no real way for the application to preven the situation from occurring.
If you have concurrent access to a TreeCache, and it happens that a couple of threads all try to write to the same Fqn (a popular item :-) then whammo.
Although using the concurrent class would be the right way to solve this, could you elaborate on what the problem is with the current ReadWriteLockWithUpgrade that does not support > 1 upgraders?
I couldn't see how things would break so tried modifying the code to see what would happen if that check was removed - all tests passed and it solved the problem we found in our app.
Pending a change in concurrent utils, any problems with just removing this check? Also, can you see a fix to the concurrent problem, if so, what is it?
Yes, we can fix this (it is a JIRA issue). However, there is a simple workaround:
- don't do a read first, do a write first, so you don't need to upgrade
The nature of the bug is described in ReentrantWriterPreferenceReadWriteLockTest.test2ReadersAnd1Writer()