yes I know.
I was just walking through the code, to see what I could see, and all
StateManagers use the global Broker lock.. so no attempt at granularity
in many places :(
Also, breaking the lock into Read/Write might give multithreaded use a
little more performance as well..
like you said, this is "battle tested code", which I am assuming is
probably like 4 years old ( from the old kodo days ). So I could
understand the hesitation to not change it, but .... you know ... :)
ps -
<crazy-brainstorm>
Another option for Slices, is to move up the 'distributed' level, so
that it maintains unique brokers or entity managers per database.. At
that point it could be a JPA Slices implementation, independent of
OpenJPA :)
It would be an DistributedEntityManager that would delegate to sub
EntityManagers, and return objects managed by the
DistributedEntityManager, but that behind the scenes would delegate to
objects owned and managed by sub EntityManagers..
So it would be like creating a JPAStoreManager that would store things
into a sub entitymanager :) etc etc
</crazy-brainstorm>
Pinaki Poddar wrote:
Since behind the scenes you are executing various different queries using
multiple
threads, and they might be touching/using shared resources lower down.
Good point, and most probably you are right.
which is to fix up QueryImpl, not to do aggressive locking (at least in
the isUnique method), and I
think it will at least remove the current blocking issue.
So far, Slice has imposed almost no demand on existing kernel -- which is
battle hardened code. So naturally, I am apprehensive of change in threading
logic in kernel.QueryImpl. Any change of this nature *must* validate itself
against a set of multithreaded tests (with or without Slice).
