Seam Persistence Context in Session scope

[sudhu72]

In a recent project, we used seam with the Seam Managed Persistence Context (SMPC) configuration in the components.xml.

We had not added the scope attribute, hence it was the default Conversational context.

But we ran into quite a few issues as Entities were getting detached as there wasn't any defined path to Begin and End conversations. Due to the entities getting detached we were forced to use Merge which at times added duplicate rows.
We changed the configuration by adding the scope attribute in the components.xml for the SMPC and defining thescope to be 'session'. This resolved our issues regarding entities getting detached.

I have questions:
1) Is there a situation (requirement) or use case where SMPC should have a session scope?

2) what is the performance impact if SMPC is bound to a session as against Conversation?

Thanks

[amitev]

I would NOT recommend a session-scoped SMPC. Everytime it loads an object it will be stored in the first-level cache for the entire session which may result to OutOfMemoryError.
I recommend you to carefully design your conversations and begin/end points. It's not that hard actually. Look at the conversation as a Unit of work. When the user opens something for edit, changes  some data and saves the changes - this is one unit of work hence one conversation.

[asookazian]

I agree with AMitev.

How did you change the SMPC scope from conversation to session?

Here is the code:

/**
 * A Seam component that manages a conversation-scoped extended
 * persistence context that can be shared by arbitrary other
 * components.
 * 
 * @author Gavin King
 */
@Scope(ScopeType.CONVERSATION)
@BypassInterceptors
@Install(false)
public class ManagedPersistenceContext {...}

If the entities are being prematurely detached, this is usually due to the persistence context closing.  If you use SMPC with Hibernate manual flush, the persistence context stays open during the LRC and this prevents Hibernate LIEs and premature detachment of entities.

[sudhu72]

I added the attribute scope="session" in the component tag for the Managed Persistence Context in components.xml.

What is the difference between flush mode manual and the default, which I believe is auto?

Also is there a best practice for how the persistence context should be opened and kept open so as to handle the LIEs as well as not affect performance adversely?

Thanks a lot



--cogito ergo sum

[amitev]

Flush-mode=auto will flush insert/update sql when the transaction commits. Flush-mode=manual will flush insert/update sql when you call .flush().

[sudhu72]

The reason I asked about manual flush is that it is tantamount to bean managed transaction.

I wanted to avoid it as a practice in a project with many developers, because if any user doesn't call flush it might result in unpredictable behaviour.

Also, if it not flushed for too long it might be as bad a persistence context with session scope.