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
