openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: slices hangs if run with Multithreaded=true
Date Fri, 12 Dec 2008 21:15:48 GMT
Not sure if this is relevant here.... for an enterprise environment  
using JTA tx, would this multithreaded slice execution involve using  
the same JTA tx on multiple threads?  This is generally not supported  
in existing transaction managers although I think there's a possible  
workaround/implementation using separate tx branches for each thread.   
Talking with other tm designers there doesn't seem to be enough demand  
for this multithreaded tx feature to support implementing it.

thanks
david jencks

On Dec 12, 2008, at 12:34 PM, Fernando Padilla wrote:

> 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