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: slices hangs if run with Multithreaded=true
Date Fri, 12 Dec 2008 20:34:20 GMT
Alright Pinaki.

So Slices Parallel Executor seems to be the root cause of the "corrupted 
queries" bug (OPENJPA-820).  My theory is that internally the Parallel 
Executor uses OpenJPA resources in a Multithreaded manner, but having 
Multithreaded=false might open it up to some concurrency issues..

You already know that I tried to test it by turning on 
Multithreaded=true, but then ran into that hanging/blocking bug.

So I simply changed the ExecutorService, to be a dumb one that only 
executes the tasks using the thread that submitted the task.. (so always 
uses the Parent Thread, so Reentrant Locks work properly) (I'll attach 
it so you see what I'm talking about ).

And so far, I do not see any of the "corrupted" queries that I was 
talking about.  But also (it might be my imagination), but it seems much 
slower too. :)


So... do you agree?  Shall we look at dismantling the ParallelExecutor 
from Slices for now ( and take the slower performance )?  While we also 
look at getting ParallelExecutor working with Multithreaded=true.  And 
also look at making OpenJPA multithreaded support be more efficient, 
because it will have to be on for ParallelExecutor to work, etc etc..



Pinaki Poddar wrote:
> This may be a tough one and thank you for sending the blocking thread stack.
> The QueryContext is shared by the parallel queries. The stack points out
> that query context is deadlocked as Executors calling QueryContext (which
> has its own lock) method on different threads. 
>   Slice has not imposed any major change on kernel's behavior (on threading
> or otherwise). But this current limitation might. The easy (and escapist)
> way out is to fall back on sequential query execution when
> openjpa.Multithreaded is set. 
> 
>   Thoughts?
> 

Mime
View raw message