tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard W. Smith, Jr." <smithh032...@gmail.com>
Subject Re: question around entityManager.flush
Date Wed, 21 May 2014 19:29:17 GMT
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