Trying to understand Seam Managed Transactions

[cbrautigam]

I'm trying to understand why my application is behaving the way it is and I've read about everything I could find in regards to Seam Managed Transactions. I'm hoping this is just my ignorance and is an easy thing to answer.

I have a Java Bean (not a stateful or stateless EJB), it marked as Session scope type. It has a method that calls out to a Stateless EJB that retrieves back entity EJB objects.

These entity EJB objects are iterated over and displayed via a rich faces data table on my xhtml page.  Some of the fields of the EJB entity are editable.

I'm noticing that after I submit the form containing the data table via a click of the command button that seam is trying to persist the data to the DB BEFORE my Java bean action method is being called.  I was anticipating that I would have to call the entitymanager persist method myself to perist the changed entity EJB objects to the DB. And in fact I need this control.  This is problematic for me because I need to do some fancy error checking on one entity EJB objects before there is an attempt to persist to the DB.  I have this error checking contained in my action method but seam is trying to persist before there is a chance it can hit my code in the Java Bean action method. I want to control when the data is persisted via calling entitymanager.persist.

I've read section 9.2. Seam managed transactions in the manual and I'm just not fully understanding how and when the transactions are started and committed.

I'm considering disabling Seam managed transactions by adding the following lines to the components.xml

<core:init transaction-management-enabled="false"/>
<transaction:no-transaction /> 

Is this the way I should go for what I want?

But I guess I'd really like to understand in more detail of why seam is trying to persist to the DB when it has not been explicitly told to.

[gjeudy]

I would recommend using Seam managed transactions. There is obviously something wrong in your case. Can you provide a detailed usecase with code samples and log entries ?

It could just be some peculiar setup in your hibernate/JPA mappings ? (I'm thinking cascading relationships here)

[javacoryd]

This is classic behavior that we and many others have seen, but makes sense after you know what is happening.

Seam, of course, allows you to throw the entity beans right up onto the JSF pages ( as backing beans ).  During the JSF lifecycle, the request values from the JSF page are applied to the backing beans which are the entities.  The entities are registered in the entity manager so they are flushed without you needing to call persist.

There are a couple of ways to get around this, but the way we have managed this is to:

1) Use a seam managed persistence context registered in components.xml.
2) Begin a conversation when the page is loaded.
3) Set the flush mode to MANUAL when the conversion is begun ( either in pages.xml or through annotations ).

This way, when you truly want to save your changes you simply call entityManager.flush().

Cory.

[gjeudy]

Cory, well understood but I don't think it answers Craig's problem.

In Seam managed transaction model, there are 2 transactions in a single JSF request cycle. One enclosing UPDATE MODEL VALUE to INVOKE APPLICATION phases inclusively and the 2nd enclosing RENDER RESPONSE phase.

If I understand correctly Craig is mentioning that the DB update is happening before the INVOKE APPLICATION phase. This doesn't make sense to me because in a regular AUTO flush mode the entityManager should only flush at the end of the transaction which means in our case at the end of the INVOKE APPLICATION phase. There are other conditions when an early DB flush could happen. (for example when querying for a newly persisted entity e.g. not yet flushed would trigger an INSERT in order for the query to succeed) but without more details from the usecase I cannot tell if these apply here.

[javacoryd]

Ah yes, thanks for clearing that up Guillaume. 

As you have mentioned, a possible flush before find is being executed for some reason before the application phase ( and after the model has been updated of course ).

Regardless, if you execute validation in the application phase and don't want the changes persisted if validation fails, you will need to either setup the manual flush mode or evict the entities from the entity manager ( this is not suggested as the lazy relationships will die ).

Craig, could you post the command button .xhtml and the action?

Thanks,

Cory.

[cbrautigam]

I'll get that posted here after holiday.  Thanks for the help.