tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: question around entityManager.flush
Date Wed, 21 May 2014 19:31:36 GMT
then the issue is the code you do needs atomicity for each JPA operation
(why you use flush). but this shouldn't be needed. Typically: create ->
edit is useless. Just create it once ;)



Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-05-21 21:29 GMT+02:00 Howard W. Smith, Jr. <smithh032772@gmail.com>:

> okay, based on what you said below,
>
> On Wed, May 21, 2014 at 2:42 PM, Romain Manni-Bucau
> <rmannibucau@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 {
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message