You were absolutely correct. I didn't catch that the SMPC was actually a Seam
Component and need to be retrieved with @In rather than @PersistenceContext.
After making this change I have learned several things and found one that I believe to be
a bug.
SMPC's only manage entity beans for the life of the conversation. This is an
important distinction between an SMPC and a persistence context obtained with
@PersistenceContext(type=PersistenceContextType.EXTENDED).
All this is fine but I still am having difficulty realizing the promise of atomic
conversations.
Merge and remove operations both get queued and executed when I flush. Unfortunately,
persist operations do not act this way.
I created a sample application with a conversation that begins on a page that lists the
users in the database. A nested conversation begins when you edit a user in the list. On
the edit page, the user is updated (merge), another entity is delete (remove), and a third
entity is created (persist). Clicking Next brings you to a confirmation screen where you
can either go back (and do another merge, remove, and persist), Submit (flush, end the
conversation, and return to the list), or Cancel (no flush, end the conversation, and
return to the list).
In this example, all merges and removes are queued until flush is called (when user clicks
Submit on the confirmation screen) but all persists happen right away regardless of
submitting/canceling.
What are your thoughts?
Thanks again,
Austin
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090063#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...