openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fernando Padilla <f...@alum.mit.edu>
Subject Re: multithreaded, read/write?
Date Wed, 17 Dec 2008 21:55:33 GMT
Wow. Thank you. At the moment I don't see any weird behavior.  Here are 
a few comments:

bug:
1) if you are going to be caching the unique value, you should clear it 
on invalidateCompilation() (for both Query and StoreQuery).  The only 
issue is that you'll have to differentiate when the unique value is set 
by user (set back to what user set), or when it was generated via 
compilation (set back to null);

code review:
2) invalidateCompilation is only called in a few places in QueryImpl, 
should they be called in a few more methods??

enhance:
3) I would still vote to review and clean up the locks in QueryImpl, 
maybe have a read/write pair, I think it could make the code much 
cleaner and performant ( locks should be within compilation methods, not 
outside, and only when they are actually compiling, etc etc ).



thank you!!  I'll keep on testing and see if I hit anything else. :)



Pinaki Poddar wrote:
> Hi Fernando,
>   Can you please pick up revision 727297 [1] and see if that works for your
> prototype/test harness?
> The changes are:
>   a) slice queries minimize lookup to their shared context for isUnique() by
> caching the unique flag. This reduces one source of thread deadlock
>   b) StateManagers use their own instance-level lock rather than locking the
> broker for everything. This reduces another source of thread deadlock. But
> this is a riskier change (though it did not show up any regression on
> OpenJPA test corpus). I am trying to find out why, at the first place,
> StateManagers were using the global Broker's lock.
>   c) all slice queries run in parallel
> 
>   I have noted that Slice should *always* run with
> openjpa.Multithreaded=true. If these changes (and similar ones but in the
> same direction -- rather than overhauling the threading model of the kernel)
> alleviate the deadlock while retaining the parallel execution at per-Slice
> level -- then I will change Slice configuration to enforce
> openjpa.Multithreaded=true.
> 
> [1]
> http://n2.nabble.com/svn-commit%3A-r727297---in--openjpa-trunk%3A-openjpa-jdbc-src-main-java-org-apache-openjpa-jdbc-kernel--openjpa-kernel-src-main-java-org-apache-openjpa-kernel--openjpa-slice-src-main-java-org-apache-o-td1666666.html
> 
> 

Mime
View raw message