Manage persistent context before flushing

Question

hi, consider hibernate-link and JTA as peristence provider. How can I force em not to flush anything, and to handle it by myself?

@Stateless 
public class SomeBean{
  @PersistenceContext
  EntityManager em;
  public void method(){
    em.persist(entity); // will get managed
    em.clear(); // everything gets unmanaged
  }
}

I would expect that there is nothing flushed into the database, but there is as I can see in the mysql shell. So how can I force EntityManager not to flush anything after persist? Thanks
persistence.xml for completeness

<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
  <persistence-unit name="pu" transaction-type="JTA">
    <provider>org.hibernate.ejb.HibernatePersistence
    <jta-data-source>jdbc/fotbalDataSource
    <properties>
      <property name="hibernate.hbm2ddl.auto" value="update"/>
    </properties>
  </persistence-unit>
</persistence>

Answer 1

How can I force em not to flush anything, and to handle it by myself?

As answered in your previous question, use em.setFlushMode(FlushType.COMMIT) if you want to avoid any automatic flush before the commit of the JTA transaction (at the end of the EJB method). Just keep in mind that there will be a flush at commit time.

I would expect that there is nothing flushed into the database, but there is as I can see in the mysql shell.

I don't think that the piece of code you're showing illustrates the above question, it's a different question here. Anyway... before going further, here is what the JPA specification says about clear():

/**
* Clear the persistence context, causing all managed
* entities to become detached. Changes made to entities that
* have not been flushed to the database will not be
* persisted.
*/
public void clear();

So clear() causes all managed entities to become detached, not unmanaged.

In other words, while the spec is a bit cloudy regarding your use case, I don't think that calling clear() is supposed to make the entity passed to persist() in your code snippet a new entity again.

I'll test this more extensively tomorrow (even if I think that this use case doesn't make much sense) and will update my answer.