You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Hans J. Prueller" <ha...@gmx.net> on 2007/03/28 21:13:54 UTC

RE: WARNING: Connection not closed by caller - messages produced byOpenJPA?

The usage case of the EM is, that I call a
PersistenceService.getEntityManager() method in every method of my
SLSB's, the SLSBs all have
the "Required" attribute set for TXs, so every time I call the getEM()
method, there should be an already running JTA TX. 

This is the code:


logger.log(Level.FINEST,
				"creating a fresh, clean EntityManager from JNDI EMF.");

		// EntityManagerFactory emf = OpenJPAPersistence
		// .createEntityManagerFactory(EMF_JNDI_LOCATION, (Context) null);

		final EntityManagerFactory emf = getEMF();

		final BrokerFactory bf = OpenJPAPersistence.toBrokerFactory(emf);

		final Broker b = bf.newBroker(bf.getConfiguration()
				.getConnectionUserName(), bf.getConfiguration()
				.getConnectionPassword(), true, // the broker is part of a JTA
managed tx
				bf.getConfiguration().getConnectionRetainModeConstant(), true); //
look for an existing Broker on the tx

		// do some JPA configuration setup. Logic stolen from
		// EntityManagerFactoryImpl.
		b.setAutoDetach(AutoDetach.DETACH_CLOSE, true);
		b.setAutoDetach(AutoDetach.DETACH_ROLLBACK, true);
		b.setDetachedNew(false);

		return OpenJPAPersistence.toEntityManager(b);


And here you have the persistence.xml:

<persistence-unit name="lbsims" transaction-type="JTA">
		<provider>
			org.apache.openjpa.persistence.PersistenceProviderImpl
		</provider>
		<jta-data-source>jdbc_lbsims</jta-data-source>
		<properties>
			<property name="openjpa.ConnectionFactoryMode"
				value="managed" />
			<property name="openjpa.ManagedRuntime"
				value="jndi(TransactionManagerName=java:comp/UserTransaction)" />
			<property name="openjpa.DataCache" value="true"/>
			<property name="openjpa.RemoteCommitProvider" value="sjvm"/>		
		</properties>
	</persistence-unit>

hth,
HANS



Am Mittwoch, den 28.03.2007, 11:54 -0700 schrieb Patrick Linskey:

> Also, how are you integrating it with the JTA transaction? Are you
> calling EM.joinTransaction(), or ensuring that the transaction is in
> progress before creating the EM, or something else?
> 
> -Patrick
> 

RE: WARNING: Connection not closed by caller -messagesproducedbyOpenJPA?

Posted by Patrick Linskey <pl...@bea.com>.
> As I mentioned, there is a static EMF in a helper class used 
> to obtain the EM's called from different
> threads. does above property also resolve multithreaded 
> access to the EMF? 

No. The EMF is always thread-safe (or should be, at least).

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -----Original Message-----
> From: Hans J. Prueller [mailto:hans.prueller@gmx.net] 
> Sent: Wednesday, March 28, 2007 10:10 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: RE: WARNING: Connection not closed by caller 
> -messagesproducedbyOpenJPA?
> 
> >> If you want to access a single EM from multiple
> >> threads, you should set the openjpa.Multithreaded property 
> accordingly
> 
> As I mentioned, there is a static EMF in a helper class used 
> to obtain the EM's called from different
> threads. does above property also resolve multithreaded 
> access to the EMF? 
> 
> Hans
> 
> Am Mittwoch, den 28.03.2007, 13:30 -0700 schrieb Patrick Linskey: 
> 
> 	
> 	> I will give it a try. Can you explicitly confirm that it 
> 	> shouldn't be a multithreading problem where there are 
> 	> serveral entitymanagers
> 	> created in different JTA transactions running in 
> parallel? e.g.
> 	
> 	Assuming that the different JTA transactions are on 
> different threads,
> 	and that you do not try to access one EM from multiple 
> threads, there
> 	should be no problem. (If you want to access a single 
> EM from multiple
> 	threads, you should set the openjpa.Multithreaded 
> property accordingly.)
> 	
> 	Also, it would be useful to see a JDBC trace-level log 
> of the system
> 	running through a couple of transactions. That might 
> give us an idea of
> 	how things are working.
> 	
> 	Are you ever sharing EMs across multiple sequential JTA 
> transactions?
> 	
> 	-Patrick
> 	
> 
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

RE: WARNING: Connection not closed by caller - messagesproducedbyOpenJPA?

Posted by "Hans J. Prueller" <ha...@gmx.net>.
>> If you want to access a single EM from multiple
>> threads, you should set the openjpa.Multithreaded property
accordingly

As I mentioned, there is a static EMF in a helper class used to obtain
the EM's called from different
threads. does above property also resolve multithreaded access to the
EMF? 

Hans

Am Mittwoch, den 28.03.2007, 13:30 -0700 schrieb Patrick Linskey:

> > I will give it a try. Can you explicitly confirm that it 
> > shouldn't be a multithreading problem where there are 
> > serveral entitymanagers
> > created in different JTA transactions running in parallel? e.g.
> 
> Assuming that the different JTA transactions are on different threads,
> and that you do not try to access one EM from multiple threads, there
> should be no problem. (If you want to access a single EM from multiple
> threads, you should set the openjpa.Multithreaded property accordingly.)
> 
> Also, it would be useful to see a JDBC trace-level log of the system
> running through a couple of transactions. That might give us an idea of
> how things are working.
> 
> Are you ever sharing EMs across multiple sequential JTA transactions?
> 
> -Patrick
> 

RE: WARNING: Connection not closed by caller -messagesproducedbyOpenJPA?

Posted by Patrick Linskey <pl...@bea.com>.
> I.e. 2 different threads accessing the EMF to create the EM 
> in parallel could be the cause of the problem?

That should not be a problem.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -----Original Message-----
> From: Hans J. Prueller [mailto:hans.prueller@gmx.net] 
> Sent: Wednesday, March 28, 2007 10:00 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: RE: WARNING: Connection not closed by caller 
> -messagesproducedbyOpenJPA?
> 
> Am Mittwoch, den 28.03.2007, 13:30 -0700 schrieb Patrick Linskey:
> 
> 
> 	Are you ever sharing EMs across multiple sequential JTA 
> transactions?
> 	
> 
> 
> As far as I can say: definitely NO. But the EMF used to 
> create the EM's is held as a static member of a Helper Class.
> I.e. 2 different threads accessing the EMF to create the EM 
> in parallel could be the cause of the problem?
> 
> Hans 
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

RE: WARNING: Connection not closed by caller - messagesproducedbyOpenJPA?

Posted by "Hans J. Prueller" <ha...@gmx.net>.
Am Mittwoch, den 28.03.2007, 13:30 -0700 schrieb Patrick Linskey:

> Are you ever sharing EMs across multiple sequential JTA transactions?


As far as I can say: definitely NO. But the EMF used to create the EM's
is held as a static member of a Helper Class.
I.e. 2 different threads accessing the EMF to create the EM in parallel
could be the cause of the problem?

Hans

RE: WARNING: Connection not closed by caller - messagesproducedbyOpenJPA?

Posted by Patrick Linskey <pl...@bea.com>.
> I will give it a try. Can you explicitly confirm that it 
> shouldn't be a multithreading problem where there are 
> serveral entitymanagers
> created in different JTA transactions running in parallel? e.g.

Assuming that the different JTA transactions are on different threads,
and that you do not try to access one EM from multiple threads, there
should be no problem. (If you want to access a single EM from multiple
threads, you should set the openjpa.Multithreaded property accordingly.)

Also, it would be useful to see a JDBC trace-level log of the system
running through a couple of transactions. That might give us an idea of
how things are working.

Are you ever sharing EMs across multiple sequential JTA transactions?

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -----Original Message-----
> From: Hans J. Prueller [mailto:hans.prueller@gmx.net] 
> Sent: Wednesday, March 28, 2007 1:08 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: RE: WARNING: Connection not closed by caller - 
> messagesproducedbyOpenJPA?
> 
> Am Mittwoch, den 28.03.2007, 12:43 -0700 schrieb Patrick Linskey:
> 
> 
> 	What happens if you set 'openjpa.TransactionMode' to 
> 'managed' as well?
> 	
> 
> 
> I will give it a try. Can you explicitly confirm that it 
> shouldn't be a multithreading problem where there are 
> serveral entitymanagers
> created in different JTA transactions running in parallel? e.g.
> 
> TX A starts
> EM A created
> A working
> TX B starts
> EM B created
> A and B working
> (this is where we currently get the errors)
> ...
> 
> 
> 
> 	Also, are you closing your EMs at the end of the transaction? 
> 	
> 
> 
> not really. the problem is that we have serveral methods 
> calling each other - each of it creating its own EM at the 
> beginning. (which
> will be the same EM instance regarding to the lookup code we 
> implementend - see previous mail). So close() of a sub-method would
> call the "outer"     methods EM too I guess?
> 
> Hans 
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

RE: WARNING: Connection not closed by caller - messages producedbyOpenJPA?

Posted by "Hans J. Prueller" <ha...@gmx.net>.
Am Mittwoch, den 28.03.2007, 12:43 -0700 schrieb Patrick Linskey:

> What happens if you set 'openjpa.TransactionMode' to 'managed' as
> well?


I will give it a try. Can you explicitly confirm that it shouldn't be a
multithreading problem where there are serveral entitymanagers
created in different JTA transactions running in parallel? e.g.

TX A starts
EM A created
A working
TX B starts
EM B created
A and B working
(this is where we currently get the errors)
...

> 
> Also, are you closing your EMs at the end of the transaction? 


not really. the problem is that we have serveral methods calling each
other - each of it creating its own EM at the beginning. (which
will be the same EM instance regarding to the lookup code we
implementend - see previous mail). So close() of a sub-method would
call the "outer"     methods EM too I guess?

Hans

RE: WARNING: Connection not closed by caller - messages producedbyOpenJPA?

Posted by Patrick Linskey <pl...@bea.com>.
What happens if you set 'openjpa.TransactionMode' to 'managed' as well?

Also, are you closing your EMs at the end of the transaction?

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -----Original Message-----
> From: Hans J. Prueller [mailto:hans.prueller@gmx.net] 
> Sent: Wednesday, March 28, 2007 12:14 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: RE: WARNING: Connection not closed by caller - 
> messages producedbyOpenJPA?
> 
> The usage case of the EM is, that I call a 
> PersistenceService.getEntityManager() method in every method 
> of my SLSB's, the SLSBs all have
> the "Required" attribute set for TXs, so every time I call 
> the getEM() method, there should be an already running JTA TX. 
> 
> This is the code:
> 
> 
> logger.log(Level.FINEST,
> "creating a fresh, clean EntityManager from JNDI EMF.");
> 
> // EntityManagerFactory emf = OpenJPAPersistence
> // .createEntityManagerFactory(EMF_JNDI_LOCATION, (Context) null);
> 
> final EntityManagerFactory emf = getEMF();
> 
> final BrokerFactory bf = OpenJPAPersistence.toBrokerFactory(emf);
> 
> final Broker b = bf.newBroker(bf.getConfiguration()
> .getConnectionUserName(), bf.getConfiguration()
> .getConnectionPassword(), true, // the broker is part of a 
> JTA  managed tx
> bf.getConfiguration().getConnectionRetainModeConstant(), 
> true); // look for an existing Broker on the tx
> 
> // do some JPA configuration setup. Logic stolen from
> // EntityManagerFactoryImpl.
> b.setAutoDetach(AutoDetach.DETACH_CLOSE, true);
> b.setAutoDetach(AutoDetach.DETACH_ROLLBACK, true);
> b.setDetachedNew(false);
> 
> return OpenJPAPersistence.toEntityManager(b);
> 
> 
> And here you have the persistence.xml:
> 
> <persistence-unit name="lbsims" transaction-type="JTA">
> <provider>
> org.apache.openjpa.persistence.PersistenceProviderImpl
> </provider>
> <jta-data-source>jdbc_lbsims</jta-data-source>
> <properties>
> <property name="openjpa.ConnectionFactoryMode"
> value="managed" />
> <property name="openjpa.ManagedRuntime"
> value="jndi(TransactionManagerName=java:comp/UserTransaction)" />
> <property name="openjpa.DataCache" value="true"/>
> <property name="openjpa.RemoteCommitProvider" value="sjvm"/> 
> </properties>
> </persistence-unit>
> 
> hth,
> HANS
> 
> 
> 
> Am Mittwoch, den 28.03.2007, 11:54 -0700 schrieb Patrick Linskey: 
> 
> 	
> 	Also, how are you integrating it with the JTA 
> transaction? Are you
> 	calling EM.joinTransaction(), or ensuring that the 
> transaction is in
> 	progress before creating the EM, or something else?
> 	
> 	-Patrick
> 	
> 
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.