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?
--
Patrick Linskey
202 669 5907
