openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fernando Padilla <>
Subject Re: slices hangs if run with Multithreaded=true
Date Fri, 12 Dec 2008 23:14:28 GMT
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 -
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

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).

View raw message