okay, based on what you said below, On Wed, May 21, 2014 at 2:42 PM, Romain Manni-Bucau <rmannibu...@gmail.com>wrote:
> @Stateless // or singletong > public class TxBean { > @PersistenceContext EntityManager em; > > public void doSomeStuffAndCommit() { > // em usage > } > } > > > when exiting the method commit will trigger flush > my @Stateless EJB has doSomeStuffAndCommit(), but doSomeStuffAndCommit() is 'usually' SQL SELECTs, and in my Abstract class for @Stateless @EJB, I have the following: protected abstract EntityManager getEntityManager(); public void create(T entity) { // 2011-09-17 flush immediately after persist/create getEntityManager().persist(entity); getEntityManager().flush(); } public void create(T entity, Boolean flush) { getEntityManager().persist(entity); if (flush) getEntityManager().flush(); } public void edit(T entity) { // 2011-09-17 flush immediately after merge getEntityManager().merge(entity); getEntityManager().flush(); } public void edit(T entity, Boolean flush) { getEntityManager().merge(entity); if (flush) getEntityManager().flush(); } public void flush() { getEntityManager().flush(); } public void remove(T entity) { // 2011-09-17 flush immediately after remove/merge the managed/detached entity getEntityManager().remove(getEntityManager().merge(entity)); getEntityManager().flush(); } public void remove(T entity, Boolean flush) { getEntityManager().remove(getEntityManager().merge(entity)); if (flush) getEntityManager().flush(); } majority of my app, calls the create(T entity), edit(T entity), and remove(T entity) methods above where flush() is called after the entityManager operation. below, is a method I have in a @Singleton bean that is called via @Schedule to get some data from email account and write data to database. again, the method below is only one of the methods that is in the @Singleton bean. private void createAuditTrail(String relatedEntityName, Object relatedEntityObj, String description) { AuditTrail current = new AuditTrail(); current.setDescriptionTx(description); try { Users user = getUser("system"); if (user == null) { logger.info("Error adding AUDIT TRAIL; 'system' user does not exist"); return; } current.setUserName(user); current.setAuditTrailId(1); current.setAuditTrailDt(new Date()); ejbFacadeAuditTrail.create(current); // add auditTrail to order if (relatedEntityName.equals("orders")) { Orders order = (Orders) relatedEntityObj; current.addOrder(order); ejbFacadeAuditTrail.edit(current); } } catch (Exception e) { logger.info("Error adding AUDIT TRAIL" + (e.getMessage() != null ? "; " + e.getMessage() : "")); } } Majority of my app is CDI @SessionScoped or @ViewScoped beans that call @Stateless @EJB to select/create/update/delete data in database. CDI @SessionScoped and @ViewScoped beans will get data via @Stateless @EJB, and CDI @SessionScoped and @ViewScoped beans may do some data manipulation, and then @Stateless @EJB is called to do the entityManager create(), edit(), remove() to update database, accordingly. The only time I write a lot of logic in @EJBs is when I am preparing for SQL SELECT. The @Singleton bean example code that I provided above is one of only (@Singleton) @EJBs that have a lot of code that does a specific job. So, when I removed entityManager.flush() from my Abstract class, earlier, per Jean-Louis's recommendation, some data was saved to database by @Singleton and most of the data was 'not' saved to database. Definition of @Singleton is below: @Singleton @Lock(LockType.WRITE) @AccessTimeout(value = 2, unit = TimeUnit.MINUTES) public class AddEmailRequest {