Actually, even my resetFlushModes() method does not seem to work. If you set one entity manager then the other entity manager is also set. I've even created a new persistence-unit, so that I could have one for the entity manager that I want to keep from auto-flushing and one that auto-flushes. However, whenever I change the flush mode of one entity manager the other entity manager's flush mode is also set. It appears that it is impossible to have two separate entity managers in Seam/Hibernate with different flush modes at the same time. Does anyone have an opinion on this?

Looking at the org.jboss.seam.persistence.PersistenceContexts (a singleton class per conversation - PersistenceContexts.instance()) code when the entity manager is being initialized via the ManagedPersistenceContext

org.jboss.seam.persistence.ManagedPersistenceContext.initEntityManager()  

  private void initEntityManager()
   {
      entityManager = getEntityManagerFactoryFromJndiOrValueBinding().createEntityManager();
      PersistenceProvider persistenceProvider = PersistenceProvider.instance();
      entityManager = persistenceProvider.proxyEntityManager(entityManager);
      setEntityManagerFlushMode( PersistenceContexts.instance().getFlushMode() );
...
}

it would appear that only one persistent context per conversation is supported in Seam.

If someone else has the same problem, a possible work around is to look up second entity manager and not let Seam inject it.

private EntityManager manualEntityManager;

@Create
@Override
public void create() {
    manualEntityManager = (EntityManager)Component.getInstance("manualEntityManager");
    ((Session)manualEntityManager.getDelegate()).setFlushMode(FlushMode.MANUAL);
}

I have a complex screen using different modules (included xhtml files) where part of it uses fast update (i.e. when the user enters data it is automatically pushed to the server using ajax on validation), and another part of the screen where values need to be validated (via ajax request) but not saved to the database until the user presses a save button. To handle the latter case, I do a look up using the standard entity manager, whose flush mode is auto, and set the individual changes from the entity that was looked up using the manual entity manager and push them to the standard one. At this point the individual changes are saved to the database as the flush mode is auto for the standard entity manager.

So, in short, I have a requirement for some changes to be auto-saved and some changes that mustn't be saved until a save button is pressed.

BTW, for the previous snippet of code to work you would also need to define the following in your components.xml file.

<persistence:managed-persistence-context name="manualEntityManager" auto-create="true"
          persistence-unit-jndi-name="java:/manualEntityManagerFactory" />

<persistence:managed-persistence-context name="entityManager" auto-create="true"
          persistence-unit-jndi-name="java:/standardEntityManagerFactory" />

Slight correction to components.xml as you can shared the same persistent unit.

<persistence:managed-persistence-context name="manualEntityManager" auto-create="true"
          persistence-unit-jndi-name="java:/myEntityManagerFactory" />

<persistence:managed-persistence-context name="entityManager" auto-create="true"
          persistence-unit-jndi-name="java:/myEntityManagerFactory" />

Of course, the JNDI name 'java:/myEntityManagerFactory' needs to correspond to the 'jboss.entity.manager.factory.jndi.name' property defined in your persistence-dev.xml and persistence-prod.xml files.

Hi Arbi,

Thanks for the response. The reason I can't use just one entity manager is because of the screen layout and business requirement. Let me explain. I have a screen (web page) where the data that is represented on the screen is from multiple entities. The screen is spit up into different parts where the user needs the ability to update different entities independently of each other. When they change some parts of the screen the changes need to be auto saved while others parts need to be delayed-saved until the user presses a save button. There are multiple save buttons on the screen to update different parts of it where one save affects some set of entities but not other entities on separate parts of the same screen.

I am trying to achieve very fine-grained control of what is saved and when it is saved on a very complex control screen.

If I used your approach when I called entityManager.flush() it would flush all changes on the screen and not just the particular ones that the user was working with. That is, the user has modified two or more parts of data on the screen, but only wants to save one part as he still hasn't made up his mind if he wants to commit the other changes that they have made.

Thanks again for your input.

Philip

Hi Arbi,

Thanks for the links - interesting reading.

The posts cover using two manual entity managers which have both their flush modes set to manual. In my specific case, I need to use one entity manager with flush mode auto and one manual to control different parts of a complex screen(s). The auto one is required as certain parts of the screen (which are very complex) have been developed separately by other developers which have used auto flush mode (actually most screens in the application use auto flushing). My particular part of the main control screen, which again is a very complex component needs deferred-save functionality, so in this case I use an entity manager with flush mode set to manual. As the project has been in development for 6 months I can't get or have the time to change all entity managers to manual flushing and use flush-on-demand. I guess we are where we are, but at least I have a solution that meets the business requirements, but without the need to change how different components work currently.

All the same, thanks for the ideas.

Cheers,

Philip