Hi,
Will someone comment on the code comments below? StateManagers using
Broker's lock amounts to a coarse-grained lock indeed. What use case
scenario prompted this change?
package org.apache.openjpa.kernel;
public class StateManagerImpl
/**
* Lock the state manager if the multithreaded option is set.
*/
protected void lock() {
// use broker-level lock to avoid deadlock situations with the state
// manager lock and broker lock being obtained in different orders
_broker.lock();
}
Fernando Padilla wrote:
>
> The stack traces are in the bug.
>
> https://issues.apache.org/jira/browse/OPENJPA-825
>
>
>
> Patrick Linskey wrote:
>> On Dec 15, 2008, at 4:10 PM, Fernando Padilla wrote:
>>
>>> The current lock contention is StateManager locks against the Broker,
>>> so essentially one global lock. If someone were to deal with that, we
>>> can move on and see where the next lock contention shows up! :)
>>>
>>> ( You can just look up who calls Broker.lock() )
>>
>> What I meant was: what is actually going on when the calls are being
>> made? Do you have any thread dumps during a bottleneck condition, for
>> example?
>>
>>> I guess the issue you're talking about is that you can't upgrade a
>>> lock from Read to Write. So if the code acquiring locks are all over
>>> the place, it would be hard to guarantee that won't be attempted..
>>
>> Yep. Synchronization in Java doesn't compose, so any additional
>> complexity make things that much more difficult, maintenance-wise.
>>
>> -Patrick
>>
>>> Patrick Linskey wrote:
>>>> Hm. My experience with read/write locks in the past has been that it
>>>> adds a fair amount of complexity, and opens up thorny issues when
>>>> someone adds code that causes a section of code to become a
>>>> write-requiring instead of a read-only section.
>>>> It might be interesting to analyze where contention starts piling up
>>>> in the context of Slice, and see if there are any creative ways to
>>>> reduce synchronization around those areas, maybe by having one lock
>>>> for EM-level data structures and another that is used within
>>>> StoreManagers. IOW, maybe there's an opportunity to transfer some
>>>> level of synchronization to the StoreManager instead of the EM, which
>>>> would mesh well with Slice's per-StoreManager parallelism.
>>>> If you go the read-write route, I think it'll be important to
>>>> maintain something close to the current pathways as the default for
>>>> existing applications (at least for a while), potentially by adding a
>>>> new openjpa.Multithreaded value ('read-write' comes to mind).
>>>> -Patrick
>>>> On Dec 15, 2008, at 1:37 PM, Fernando Padilla wrote:
>>>>> So, if you guys have been following the mailing list, we've been
>>>>> having some issues with slices requiring multithreaded support, but
>>>>> the multithreaded support uses mostly a global lock, thus negating a
>>>>> huge performance gain used by Slices, where it executes queries in
>>>>> parallel.
>>>>>
>>>>> So it looks like a long-term solution would be to review the locks
>>>>> within OpenJPA and try to make them much more granular, but this
>>>>> looks like it might be a very hard thing to do without everyone's
>>>>> help, lots of unit tests, etc etc..
>>>>>
>>>>> I was wondering about another option, is to use Read/Write locks.
>>>>> Maybe that will allow more granularity, allowing more threads to do
>>>>> more work, without drastically changing the way things work. ( We
>>>>> would change all current locks to be writeLocks, then slowly change
>>>>> them to readLocks on a case by case basis..)
>>>>>
>>>>> What are your thoughts towards an idea like this?
>>>>> If I can start to submit a few patches, would they be totally ignored?
>>
>
>
--
View this message in context:
http://n2.nabble.com/multithreaded%2C-read-write--tp1660098p1666580.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.
