tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mikeho <>
Subject Re: Embedded OpenEJB does not seem to be flushing to the DB on commit
Date Wed, 02 Sep 2009 13:00:25 GMT


I finally figured out what the issue was. It turns out that it was not
OpenEJB but rather a eclipselink property when creating the
EntityManagerFactory outside the container. 

Here is the extract from the elipselink

 Specify the name by which the EclipseLink session is stored in the static
session manager. Use this option if you need to access the EclipseLink
shared session outside of the context of the JPA or to use a pre-existing
EclipseLink session configured through an EclipseLink sessions.xml file. 

Valid values: a valid EclipseLink session name that is unique in a server

Example: persistence.xml file 

<property name="eclipselink.session-name" value="MySession"/>
Example: property Map 

import org.eclipse.persistence.config.PersistenceUnitProperties;
propertiesMap.put(PersistenceUnitProperties.SESSION_NAME, "MySession");  



David Blevins wrote:
> On Aug 19, 2009, at 8:19 AM, mikeho wrote:
>> Hi Daivid,
>> Firstly thanks for the reply.
>> My aim is to use the Fit framework and embedded OpenEJB to test an
>> application.
>> I intend using fit fixtures to set up test data and fit fixtures to  
>> invoke
>> the various session beans.
>> So in my test setup I beginTx() write a row to the db and commitTx()
>> I then insert another entity (for the same table) via the SSB (default
>> transaction settings ie CMP tx.required).
>> I then invoke a method on the SSB which should return a list of all  
>> the
>> entities in the table. This is the result list I refer to earlier.  
>> This list
>> only contains the rows I commited in the setup. The entity inserted  
>> via the
>> SSB is not in the list.
> Ok, I see.  If you can create a small test case for this, I'll be  
> happy to take a look.
> A side note on acronyms, I think you mean CMT (Container-Managed  
> Transactions) instead of CMP (Container-Managed Persistence).  CMP was  
> the old javax.ejb.EntityBean persistence model that was obsoleted by  
> the new javax.persistence API.
>> Feed-back
>> (A) I assume then that if I do a lookup of the EntityManagerFactory  
>> (or get
>> injected into my #LocalClient) that ny EMs created by it will be  
>> able to
>> access the entities inserted/updated by the container?
> Right.  I doesn't matter what persistence technology does the  
> inserting/updating as long as the data is flushed to the database.   
> Using two at the same time in the same transaction would be a big no- 
> no, but it doesn't sound like you're doing that.
>> I could use this
>> mechanism to set up my test fixtures. Would I use the  
>> UserTransaction or the
>> EntityTransaction API to begin/commit these transactions?
> Sure, we have an example that does exactly that using the  
> UserTransaction:
> Here the setup is done in the test case via directly using an  
> EntityManagerFactory.  The entities inserted are later read via a  
> Stateful bean using an EntityManager.
>> (B) The containers db pool is indeed pinting to the same db and is  
>> container
>> managed. You correct in your assumption that there is no active  
>> transaction
>> when the methods on the SSB are invoked. And what you describe is the
>> behaviour that I expected.
>> (C) the insert and read methods are on the same Stateless Session  
>> Bean and
>> reference the same EJB entity.
>> I am very excited by the benefits that this product offers in  
>> testing. Both
>> for functional and regression testing.
> There's likely something simple going on.  Should be pretty clear with  
> a small test case to reproduce the situation.
> -David

View this message in context:
Sent from the OpenEJB User mailing list archive at

View raw message