geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: JPA, entities and EJB3
Date Thu, 12 Jun 2008 02:14:26 GMT

On Jun 9, 2008, at 1:43 AM, Phani Madgula wrote:

> Hi,
> I have tried to play with <jta-datasource> and <non-jta-datasource>  
> as follows.
> I have the following peristence.xml in a web application.
>    <persistence-unit name="Tutorial" transaction- 

> In the servlet, I have the following code
> @PersistenceContext(unitName="Tutorial")
>   private EntityManager em;
> .....
> ....
> 		UserTransaction ut;
> 		try{
> 			Context ctx = new InitialContext();
> 			//ut = (UserTransaction)ctx.lookup("java:comp/UserTransaction");
> 			//ut.begin();
> //Uncomment EntityTransaction
> 			EntityTransaction et = em.getTransaction();
> 			et.begin();
> 			Book book = new Book("DDDDD","John", 
> 1.0,"Joe","1934834-23823","Phani");
> 			em.persist(book);
> 		        et.commit();
> 			//ut.commit();
> 		}catch(Exception e){
> 			e.printStackTrace();
> 			throw new ServletException (e);
> 		}
>  ***********************
>  I get the following error
>  ***********************
>  java.lang.IllegalStateException : You can not call getTransaction on
> a container managed EntityManager


> Please note that I am using "RESOURCE_LOCAL" persistence unit.

You're in the right direction.  Try modifying this part of your  
servlet as follows:

[cut this part]
private EntityManager em;

[redo as]
private EntityManagerFactory emf;

The use of RESOURCE_LOCAL definitely requires you to use the  
EntityTransaction API as you were attempting to do.  It also requires  
you to use the EntityManagerFactory to get your EntityManager.  The  
implication of the RESOURCE_LOCAL is that the EntityManager instance  
you create from the factory *is* the entire persistence context, cache  
and all (EntityManger instance == PersistenceContext, terminology  
wise).  For illustrative purposes it's safe to imagine big "cache"  
hashmap as a field inside the EntityManager instance you created.   
It's not entirely how most providers do it, but the technical  
ramifications are the same.  One of the ramifications is that if you  
want someone else to do persistent operations with the same  
persistence context you need to find a way to get them the  
EntityManager instance you created.  From a spec perspective we (EJB  
3.0 spec hat on) could have allowed you to reference a RESOURCE_LOCAL  
unit via an EntityManager reference, but the trick is that each  
reference would wind up creating a new EntityManager instance, cache  
and all, and you could make a really big mess; seemed better to just  
force you to create the instance yourself and share it however you  
feel best so that there could be no misunderstandings.

With a TRANSACTION unit you are in fact required to lookup or have  
injected the EntityManager and are not allowed to use the  
EntityManagerFactory or the EntityTransaction API.  As a vendor what  
we do underneath the covers is give you an EntityManager wrapper that  
points to nothing.  Then when a transaction is started (via  
UserTransaction or a container transaction) we use the  
EntityManagerFactory to create an EntityManager instance and make all  
the wrappers point to it.  When the transaction commits, the internal  
EntityManager instance is discarded (cache goes bye-bye) and wrappers  
again point to nothing.  This is essentially why you need a  
transaction in progress to use a EntityManager with JTA scope and  
TRANSACTION unit.  With an EXTENDED PersistenceContext (again,  
available only with a TRANSACTION unit) things work pretty much the  
same except that the internal EntityManager instance is *not*  
discarded and the end of transactions (cache stays in memory and can  
be used again in another transaction), instead it lives as long as the  
Stateful session bean holding it.

> My questions are
> 1. Should we always use UserTransaction object irrespective of
> <jta-datasource> or <non-jta-datasource> in JEE environment??
> 2. How is the use of <non-jta-datsource> different from the use
> <jta-datasource> in JEE environment??
> 3. In EJBs, when ContainerManaged Transactions are used, there is no
> need to use JTA. Is that correct??
> 4. Only in J2SE environments, we can use EntityTransaction object. is
> that correct??

Hopefully the above explanation answers these questions (good  
questions, BTW).  If anything is still unclear, definitely don't  
hesitate to ask for more information or for something to be simply  
reworded (can be hard trying to find the right way to explain these  


> On 5/28/08, David Jencks <> wrote:
>> 1. I hope you named the file openejb-jar.xml
>> 2. jta-datasource and non-jta-datasource have to contain the names of
>> the datasources in the geronimo plan used for the pool, NOT some jndi
>> name you might also map them to.  The datasources don't need to be
>> bound in jndi in order to be used for jpa
>> 3. The non-jta-datasource must be a datasource that really has no
>> transaction support, using the <no-transaction/> element instead of
>> <local-transaction/> or <xa-transaction>... in the connector plan.
>> With derby I find it necessary to have a non-jta-datasource if any  
>> ddl
>> is needed or if openjpa is generating the primary keys.  I don't know
>> if you can get away without one for other databases.  If you want to
>> experiment, leave out the non-jta-datasource rather than duplicating
>> the jta-datasource contents.
>> hope this helps
>> david jencks
>> On May 27, 2008, at 4:09 PM, zeros wrote:
>>> Good evening:
>>>   I'm newbie with EJB3.0. I want to configure the persistence.xml
>>> to have
>>> entities managed with JPA. I have the next configuration files:
>>> <openejb-jar xmlns=""
>>> xmlns:nam=""
>>> xmlns:pkgen=""
>>> xmlns:sec=""
>>> xmlns:sys="">
>>> <sys:environment>
>>>   <sys:moduleId>
>>>     <sys:groupId></sys:groupId>
>>>     <sys:artifactId>EJB</sys:artifactId>
>>>     <sys:version>1.0.8</sys:version>
>>>     <sys:type>jar</sys:type>
>>>   </sys:moduleId>
>>>   <sys:dependencies>
>>>       <sys:dependency>
>>>           <sys:groupId>console.dbpool</sys:groupId>
>>>       	<sys:artifactId>marketing</sys:artifactId>
>>>       	<sys:version>1.0</sys:version>
>>>         	<sys:type>rar</sys:type>
>>> 		</sys:dependency>
>>> </sys:dependencies>
>>> </sys:environment>
>>> </openejb-jar>
>>> And I have also persistence.xml
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <persistence version="1.0" xmlns="
>>> "
>>> xmlns:xsi=""
>>> xsi:schemaLocation="
>>> <persistence-unit name="marketing">
>>>   	<description>Entity Beans for User</description>
>>> <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</
>>> provider>
>>>   	<jta-data-source>java:comp/env/marketing</jta-data-source>
>>>   	<non-jta-data-source>java:comp/env/marketing</non-jta-data- 
>>> source>
>>>       <mapping-file>META-INF/orm.xml</mapping-file>
>>>       <properties />
>>> </persistence-unit>
>>> </persistence>
>>> The error which I'm having is the next one: Unable to resolve
>>> reference
>>> "JtaDataSourceWrapper" and Unable to resolve reference
>>> "NonJtaDataSourceWrapper", which are basically the same error.
>>> I think this is produced because I'm not mapping the Datasocurce to
>>> the
>>> DBPool. Geronimo returns to me examples to do it for web, but no
>>> example to
>>> do it for an EJB.
>>> Please could you help me?
>>> WATCH OUT! I'm talking about entities and EJB3.0, not entiti beans  
>>> and
>>> EJB2.0
>>> Thanks in advance
>>> --
>>> View this message in context:
>>> Sent from the Apache Geronimo - Users mailing list archive at

View raw message