Form submit trigger many updates

[milesif]

Hi everybody,

I have a class based on the "Seam APplication Framework" defined as

 @Name("machineHome")
 class MachineHome extends EntityHome<Machine>

I submit a form whose fields are bound to variables of type

 #{machineHome.instance.fieldName}

calling the action (I overrid the method just to play with exceptions)

 @Override
 @Transactional
 public String update()
 {
 try {
 getEntityManager().joinTransaction();
 getEntityManager().flush();
 updatedMessage();
 return "updated";
 } catch (Exception e) {
 e.printStackTrace();
 return "";
 }
 }

When I submit the form I see the following log message

00:32:57,454 INFO [STDOUT] Hibernate: update public.machines set version=?, start_date=?, status=?, id_unit=?, machine_code=?, purchase_date=?, last_maintenance_date=?, dismission_date=?, expected_life=?, id_machine_type=?, maintenance_category=? where id_machine=?

I see it as many times as the number of fields I modified before submitting the form.
This happens if in faces-config.xml I set

<lifecycle>
 <phase-listener>
 org.jboss.seam.jsf.SeamPhaseListener
 </phase-listener>
</lifecycle>

while it does not happen if I set

<lifecycle>
 <phase-listener>
 org.jboss.seam.jsf.TransactionalSeamPhaseListener
 </phase-listener>
</lifecycle>

In both cases the entity manager get flushed (and the changes saved) even if I do not call flush() explicitely and when I call a method that is not tagged as @Transactional.
Can anybody help me to understand why that happens and how to flush the entity manager only when I call flush explicitely? Should I use a @Stateful session bean ?

Thanks to anybody for help.

Ciao Francesco

[norman.richards]

Unfortunately, certain members of the spec committee kept this from being a standard flush mode for a JPA persistence context. Hibernate supports this, and seems gives access to it through @Begin(flushMode=MANUAL) and by setFlushModeManual() on the persistence provider component.

[hstang]

Using a TransactionalSeamPhaseListener:
A non JSF request (a redirect for example)--transaction begins just before restore_view(rv) phase, and the same transaction commits just after rv. A second transaction begins before render response phase (rr), and commits after it.

For a JSF request(e.g. submit)--tx begins just before rv phase, and commits just after invoke application phase (after completion of your action method). Similarly to non jsf request, a second transaction begins before rr phase, and commits after.

That's why there isn't need to do explicit flush. If you really want to do that though, you can look into using atomic conversations. Set the flushModeType to manual, then Seam will only flush when you tell it to. The docs should have more about it. Good luck.

[milesif]

Thanks Richard and hstang,

ok, I will try setting flushModeType to manual.

Anyway, there are a few things that are not yet clear and I am curious about:
1. why with the SeamPhaseListener I get many updates as the number of values I changed in the form: maybe it is just a repeated log message while there is only one sql update command sent to the database?
2. it is possible that with the SeamPhaseListener some changes are applied before and some after my action method is called? Does this make sense?
3. how SeamPhaseListener manages transaction? Or it does not?

thanks again to everybody

Ciao Francesco

[norman.richards]

1 - I'm not sure. My guess is that each of those operations is happening in a new transaction. It wouldn't happen with the transactional phase listener because there would be one transaction covering all of the operations.

2. The changes are applied to the entity in the update model values phase, which is before the invoke application phase.

3. It doesn't. Use the TransactionalSeamPhaseListener for Seam to manage the transaction.