Seam Managed Persistence Context Scope "page": is this a good idea?

[viviansteller.vivian.steller.uni-ulm.de]

Hello,

basically my question is if there are any concerns (performance wise etc.) setting the scope of a seam managed persistence context to PAGE instead of the default one CONVERSATION? I ask this because in my application I observe the occurrence of stale data when multiple users (or multiple tabs) edit or view the same entities.

Consider the following scenario: I use a seam managed persistence context (default scope this time) injected into a stateless session bean to manage let's say Lecture entities. I open two tabs in my browser with two different long-running conversations being active. In tab 1 I display a list of lectures using a normal JPA query result list that was returned by one method of the stateless session bean (which, again, uses a @Injected EntityManager). In tab 2 I edit an entity of the list and also pass it to one of the methods of the stateless session bean (and this as well uses its own @Injected EntityManager to save the entity). Having saved the entity in tab 2 everything is displayed quite fine in this conversation and also the database is updated with the new values. So far so good.

However, reloading tab 1 with the same conversation id in place now does not fetch the updated entity from the DB again, which seems pretty odd to me.

At first I plugged in my eclipse debugger and checked that indeed the entity manager (aka query.getResultList()) returns stale data. While debugging I also executed entityManager.refresh(lecture) on the updated entity and after that the result was fine, the entity was refreshed with the correct data that was inserted in tab 2. While this would work, I think it is a pretty bad idea to refresh each entity in a result list with possibly a hundred of objects.

Thus, I tried setting the scope of the seam managed persistence context to PAGE which helped out as well. Now, seam injects a new entity manager instance on each request and this one fetches up-to-date data from the DB as expected.

So again, my questions: is this the right behavior of the managed persistence context? I've never seen anyone else setting the scope of the seam managed persistence context to something else than the default, but how do they achieve consistent data across different conversations? Maybe some query hints could solve the problem as well? Do you have any idea (using Hibernate Persistence)?

Thanks a lot for your input!

[pmuir]

What you are seeing is the correct behaviour - conversations are isolated from one another. If you are wanting your entities refreshed, either call refresh() or reconsider your use of conversations.

A couple of problems with your approach:

1. How are you planning on serializing the entity manager to page scope?


2. How is getting a new entity manager every request any more performant than refreshing an entity (each new entity manager must do a load equivalent to the refresh)

[viviansteller.vivian.steller.uni-ulm.de]

Thanks, Pete for your prompt response.

Well, you are perferctly right with your arguments. Seeing the second one written down, it convinces me that searching an in memory list picking up a single updated item and refresh it is doubtless more performant than getting a new entity manager and picking up the complete list again. True.

About serializable: the EntityManagerProxy used by Seam implements Serializable, that's I guess why it works. (But having said this just for completeness.)

But again about conversations: you say it's their purpose to isolate stuff from one another. I agree with you and this true in general, however, asking an entity manager of any scope to load a bunch of data that IS already in the DB should return in the same result? I thought that kind of isolation is covered by transactions? It seems that there is some kind of cache for query results, is that right? Or are only those items not yet attached to an entity manager loaded from the DB? (knowing that this is maybe no more related to Seam conversation, I appreciate any insights you have for me pretty much;)

So, again, thanks a lot for your reply.

[admin.admin.email.tld]

What you're asking about falls in line with best practices with multiple simultaneous conversations in a Seam app from the same client.

I'm wondering why you're using CONVERSATION scope with a SLSB, typically you use a SFSB as a conversation component (and with LRC with @Begin and @End to demarcate the start and finish of the conversation).

I'm wondering if this scenario is covered in the upcoming Seam books.  Not sure I read about this in the Seam ref doc.

[pmuir]

Ok, for hibernate, you can serialize the EntityManager. Seam conversations extend the data isolation length from a system transaction to the length of a users natural transaction with the application. The persistence context caches the database lookup, yes. This is all expected and correct.