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...