You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Michael Pflueger <Mi...@sma.de> on 2011/09/12 19:36:52 UTC

OpenJPA (with slice) multithreaded scaling issues

Hi,
I tried to access a sliced database with multiple threads, each thread using its own entity manager.
However, that gained almost no speed advantage at all, because each thread reading from the sliced db seems to block the other threads(I have not specifically tested to make them explicitly read from different slices, but it should occur aswell, and yet I hardly see more than one thread running at the same time).

Now, as JDBC can read the data quite a bit faster than OpenJPA, the database itself could handle a higher load and OpenJPA adds overhead in Java - which currently does seem to scale badly across multiple Threads, at least with slice, unless I'm missing something. Here's a lock trace:

	at java.util.concurrent.locks.LockSupport.park(Unknown Source)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown Source)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(Unknown Source)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Unknown Source)
	at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(Unknown Source)
	at java.util.concurrent.locks.ReentrantLock.lock(Unknown Source)
	at org.apache.openjpa.slice.ReentrantSliceLock.lock(ReentrantSliceLock.java:46)
	at org.apache.openjpa.slice.DistributedBrokerImpl.lock(DistributedBrokerImpl.java:141)
	at org.apache.openjpa.kernel.BrokerImpl.getCachePreparedQuery(BrokerImpl.java:5075)
	at org.apache.openjpa.kernel.DelegatingBroker.getCachePreparedQuery(DelegatingBroker.java:1445)
	at org.apache.openjpa.persistence.EntityManagerImpl.getPreparedQueryCache(EntityManagerImpl.java:1083)
	at org.apache.openjpa.persistence.QueryImpl.preExecute(QueryImpl.java:564)
	at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:314)
	at org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:331)

Openjpa.multithreaded is not enabled, LockManager set to None, ConnectionRetainMode is set to "always".
I have not yet tested this scenario without slice, so the problem may not be slice related.

So, can't each entity manager have its own sliced connection or is there another way to get around these locks?

Michael
___________________________________________________

SMA Solar Technology AG
Aufsichtsrat: Guenther Cramer (Vorsitzender)
Vorstand: Juergen Dolle, Roland Grebe, Uwe Hertel, Pierre-Pascal Urbon, Marko Werner
Handelsregister: Amtsgericht Kassel HRB 3972
Sitz der Gesellschaft: 34266 Niestetal
USt-ID-Nr. DE 113 08 59 54
WEEE-Reg.-Nr. DE 95881150
___________________________________________________


AW: AW: OpenJPA (with slice) multithreaded scaling issues

Posted by Michael Pflueger <Mi...@sma.de>.
Hi,
are there any news about this issue?
Should I open a bugreport about this?

Michael

-----Ursprüngliche Nachricht-----
Von: Michael Pflueger [mailto:Michael.Pflueger@sma.de] 
Gesendet: Dienstag, 13. September 2011 18:58
An: users@openjpa.apache.org
Betreff: AW: AW: OpenJPA (with slice) multithreaded scaling issues

Right.
Attached is a my test project again, this time including a threaded test (FetchThreadedJpaTest).
My Observations are, that the two threads block each other when using slice and accessing the same single slice(I have not tested accessing different slices).
When you use the "openjpa" persistence unit instead of the "slice" unit, the two threads do NOT block each other but run happily at the same time, and the whole program runs about twice as fast.

So it seems slice is the issue here that's causing this blocking.

Michael

-----Ursprüngliche Nachricht-----
Von: Pinaki Poddar [mailto:ppoddar@apache.org]
Gesendet: Dienstag, 13. September 2011 18:51
An: users@openjpa.apache.org
Betreff: Re: AW: OpenJPA (with slice) multithreaded scaling issues

Michael,
  1. openjpa.Multithreaded=false -- right?
  2. A single user thread is accessing each entity manager -- right? That is no entity manager is being accessed by more than one concurrent thread. 


-----
Pinaki Poddar
Chair, Apache OpenJPA Project
--
View this message in context: http://openjpa.208410.n2.nabble.com/OpenJPA-with-slice-multithreaded-scaling-issues-tp6784525p6788333.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
___________________________________________________

SMA Solar Technology AG
Aufsichtsrat: Guenther Cramer (Vorsitzender)
Vorstand: Juergen Dolle, Roland Grebe, Uwe Hertel, Pierre-Pascal Urbon, Marko Werner
Handelsregister: Amtsgericht Kassel HRB 3972 Sitz der Gesellschaft: 34266 Niestetal USt-ID-Nr. DE 113 08 59 54 WEEE-Reg.-Nr. DE 95881150 ___________________________________________________

AW: AW: OpenJPA (with slice) multithreaded scaling issues

Posted by Michael Pflueger <Mi...@sma.de>.
To add to my last mail, I tried this both with and without FetchBatchSize enabled, and the results are similar, with slice the threads block each other, without they don't.

Michael
___________________________________________________

SMA Solar Technology AG
Aufsichtsrat: Guenther Cramer (Vorsitzender)
Vorstand: Juergen Dolle, Roland Grebe, Uwe Hertel, Pierre-Pascal Urbon, Marko Werner
Handelsregister: Amtsgericht Kassel HRB 3972
Sitz der Gesellschaft: 34266 Niestetal
USt-ID-Nr. DE 113 08 59 54
WEEE-Reg.-Nr. DE 95881150
___________________________________________________


AW: AW: OpenJPA (with slice) multithreaded scaling issues

Posted by Michael Pflueger <Mi...@sma.de>.
Right.
Attached is a my test project again, this time including a threaded test (FetchThreadedJpaTest).
My Observations are, that the two threads block each other when using slice and accessing the same single slice(I have not tested accessing different slices).
When you use the "openjpa" persistence unit instead of the "slice" unit, the two threads do NOT block each other but run happily at the same time, and the whole program runs about twice as fast.

So it seems slice is the issue here that's causing this blocking.

Michael

-----Ursprüngliche Nachricht-----
Von: Pinaki Poddar [mailto:ppoddar@apache.org] 
Gesendet: Dienstag, 13. September 2011 18:51
An: users@openjpa.apache.org
Betreff: Re: AW: OpenJPA (with slice) multithreaded scaling issues

Michael,
  1. openjpa.Multithreaded=false -- right?
  2. A single user thread is accessing each entity manager -- right? That is
no entity manager is being accessed by more than one concurrent thread. 


-----
Pinaki Poddar
Chair, Apache OpenJPA Project
--
View this message in context: http://openjpa.208410.n2.nabble.com/OpenJPA-with-slice-multithreaded-scaling-issues-tp6784525p6788333.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
___________________________________________________

SMA Solar Technology AG
Aufsichtsrat: Guenther Cramer (Vorsitzender)
Vorstand: Juergen Dolle, Roland Grebe, Uwe Hertel, Pierre-Pascal Urbon, Marko Werner
Handelsregister: Amtsgericht Kassel HRB 3972
Sitz der Gesellschaft: 34266 Niestetal
USt-ID-Nr. DE 113 08 59 54
WEEE-Reg.-Nr. DE 95881150
___________________________________________________

Re: AW: OpenJPA (with slice) multithreaded scaling issues

Posted by Pinaki Poddar <pp...@apache.org>.
Michael,
  1. openjpa.Multithreaded=false -- right?
  2. A single user thread is accessing each entity manager -- right? That is
no entity manager is being accessed by more than one concurrent thread. 


-----
Pinaki Poddar
Chair, Apache OpenJPA Project
--
View this message in context: http://openjpa.208410.n2.nabble.com/OpenJPA-with-slice-multithreaded-scaling-issues-tp6784525p6788333.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

AW: OpenJPA (with slice) multithreaded scaling issues

Posted by Michael Pflueger <Mi...@sma.de>.
Hi,
that did not seem to help, the lock trace remains exactly the same.
Locks also occur on EntityManager.clear() btw:

	at java.util.concurrent.locks.LockSupport.park(Unknown Source)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown Source)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(Unknown Source)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Unknown Source)
	at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(Unknown Source)
	at java.util.concurrent.locks.ReentrantLock.lock(Unknown Source)
	at org.apache.openjpa.slice.ReentrantSliceLock.lock(ReentrantSliceLock.java:46)
	at org.apache.openjpa.slice.DistributedBrokerImpl.lock(DistributedBrokerImpl.java:141)
	at org.apache.openjpa.kernel.BrokerImpl.beginOperation(BrokerImpl.java:1927)
	at org.apache.openjpa.kernel.BrokerImpl.detachAll(BrokerImpl.java:3396)
	at org.apache.openjpa.kernel.DelegatingBroker.detachAll(DelegatingBroker.java:1206)
	at org.apache.openjpa.persistence.EntityManagerImpl.clear(EntityManagerImpl.java:1158)

I might try to create a small testcase to show the problem..

-----Ursprüngliche Nachricht-----
Von: Pinaki Poddar [mailto:ppoddar@apache.org] 
Gesendet: Dienstag, 13. September 2011 06:49
An: users@openjpa.apache.org
Betreff: Re: OpenJPA (with slice) multithreaded scaling issues

Michael,
  The lock contention seems to be at a different place than at JDBC layer.
Can you please set
openjpa.jdbc.SQLQueryCache=false and see if th elock contention is reduced?


-----
Pinaki Poddar
Chair, Apache OpenJPA Project
--
View this message in context: http://openjpa.208410.n2.nabble.com/OpenJPA-with-slice-multithreaded-scaling-issues-tp6784525p6786203.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
___________________________________________________

SMA Solar Technology AG
Aufsichtsrat: Guenther Cramer (Vorsitzender)
Vorstand: Juergen Dolle, Roland Grebe, Uwe Hertel, Pierre-Pascal Urbon, Marko Werner
Handelsregister: Amtsgericht Kassel HRB 3972
Sitz der Gesellschaft: 34266 Niestetal
USt-ID-Nr. DE 113 08 59 54
WEEE-Reg.-Nr. DE 95881150
___________________________________________________


Re: OpenJPA (with slice) multithreaded scaling issues

Posted by Pinaki Poddar <pp...@apache.org>.
Michael,
  The lock contention seems to be at a different place than at JDBC layer.
Can you please set
openjpa.jdbc.SQLQueryCache=false and see if th elock contention is reduced?


-----
Pinaki Poddar
Chair, Apache OpenJPA Project
--
View this message in context: http://openjpa.208410.n2.nabble.com/OpenJPA-with-slice-multithreaded-scaling-issues-tp6784525p6786203.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.