I encountered a strange behaviour of the Seam Managed Persistence Context, when used in conversation scope. When using the default flush mode, I would expect that the persistence context is flushed at least once for each request that is processed within this conversation. But I experienced that flushing only occurs when the SMPC is explicitly used during the request. The implication is that changes made to managed entities during a request are not guaranteed to be synchronized with the database in the same request.
In request 1, conversation scoped Seam component A uses the SMPC for fetching an entity X. It assigns entity X to a property of another (injected) Seam component B, which is in conversation scope as well.
In request 2, component B updates a property of entity X. This makes the persistence context dirty, but it is not flushed to the database.
When analyzing this issue, I saw that the persistence context is joined with the transaction in the ManagedPersistenceContext class of the Seam framework, as soon as
entityManager is unwrapped into the conversation. That explains my observations.
I have a workaround: if a Seam component changes properties of managed entities, without explicitly injecting the SMPC, just add a dummy injection of the SMPC. But a question remains: why is Seam behaving like this? Wouldn't it be better to let the SMPC join each transaction that is started within the context of the conversation?