Conversation and Manual Flush Mode

[dapeng]

Hi,

I hope that I understand everything in the right way. Seam always starts and commits 2 Tx for each request. By default flush type of AUTO, hibernate entity manager will also commit the 2 txs. (Is there an optimization to handle the second tx for render response phase in a read-only mode? Don't think it is always reasonable, but just curious to know) In a long-running conversation over several request, this commitment of tx leads to a database flush, which is actually not wished. So the right strategy is to use the manual flush mode and flush explicitly at the end of conversation.

I hope I got the right understanding so far. It will be great if you guys can give a short conformation.

Now my question: I am using Seam in a layered architecture, in which the I would not like to expose the entity manager into the JSF layer. I know this is not the Seam philosophy, but it is a fact. Do you have a suggestion, how I can handle this manual flush at the end of the conversaton in a elegant way.

Option 1 is to define corresponding methods in "service backend" (for @End), which always invoke entityManager.flush(). This could limit the reusability of these methods, because they can be used in environments where auto flush is more appropriate.
Option 2 is to introduce a FlushService, which can be used by JSF beans to start the flush. But I don't like this idea either, because it is really not natural.

I am really keen to know whether you have better ideas.

Thx in advance.

[pmuir]

Don't confuse transaction commits with flushing the persistence context flushes. Manual flush mode doesn't alter the transaction commits at all.

I don't really understand what you are after? You want to interpose a control layer that just exposes the EntityManager methods but with a non standard API? Doesn't sound sensible to me.

[dapeng]

Hi, Pete,

I know the difference bet. tx-commit and persistence context flush. My question is, whether the manual flush is always the best strategy for a conversation, when I don't want to see modified data in the database permaturely, before the conversation is completed.

in Seam examples and documentation the manual flush is called in the JSF layer. But in my layered application, I would not like to expose the entitymanager to the JSF layer but to keep in the "backend layers" (service + dao).

Do you have a suggestion, how to handle the manual flsuh without exposing the entity manager in the jsf layer?

[pmuir]

"dapeng" wrote:
I know the difference bet. tx-commit and persistence context flush.

Good :) - a common mistake!

My question is, whether the manual flush is always the best strategy for a conversation, when I don't want to see modified data in the database permaturely, before the conversation is completed.

IMO, yes.

in Seam examples and documentation the manual flush is called in the JSF layer. But in my layered application, I would not like to expose the entitymanager to the JSF layer but to keep in the "backend layers" (service + dao).

You can control the flushmode both through annotations/xml and programatically through PersistenceProvider.instance().setManualFlushMode(em); You have to use a Seam Managed Persistence Context though. I would probably make the service layer set the flush mode, but then this is definitely not how I would design an application.

[dapeng]

How will you then design your application? Get rid of the layered architecture?

You can control the flushmode both through annotations/xml and programatically through PersistenceProvider.instance().setManualFlushMode(em); You have to use a Seam Managed Persistence Context though. I would probably make the service layer set the flush mode, but then this is definitely not how I would design an application.

I chose a solution where I use an aspect to flush the persistence context after invocation of all methods with @End annotation. Any comment? I tried to do the same to switch the flush mode to manual on all methods with @Begin annotation. But this didn't work as expected. It seems that the javaassist code instrumentation overwrites or got messed up with the aspectj instrumentation. Maybe I'd better choose Seam interceptor instead of Aspectj. Only in that case I have to either reference the interceptor or an annotation based on the interceptor in all action classes. Do you have a better idea, how to solve this problem? Can I put the annotation once in an abstract super class?

Thx.

[pmuir]

Take a look at the wiki example, this uses some simple layering.

Interceptors have to be placed on each Seam component (we have an open jira to allow custom interceptors to be applied across selected components).

[joaobmonteiro]

"dapeng" wrote:
Hi,

I hope that I understand everything in the right way. Seam always starts and commits 2 Tx for each request. By default flush type of AUTO, hibernate entity manager will also commit the 2 txs. (

Hi, I really need to understand when Seam starts a new transaction. I saw that you realize how it happens. Could you tell me you source of this information or explain it better?

I have a similar situation (service + dao) and some problems with transactions because flush() is called after any dao operation, and many times I do not desire that.

Thanks!

[dapeng]

If you have transaction enabled in seam, it will start 1 tx for phase 1 to 5 of JSF lifecycle. Then commits the 1 tx, which should lead to a flush. Then Seam will start a 2 tx for phase 6 of JSF lifecycle and immediately commits that after that.