1) TX.NOT_SUPPORTED is quite interesting, too. I mean sometimes you have a backing SFSB that provides additional functionality e.g. validation that can't be done directly in JSF (e.g. comparing two entered passwords like in user registration). You sure don't want flush() to be called after that ;). So that's an important tip, thanks. 2) But I still have problems understanding those LazyInitalisationExceptions. I mean, look at that example code: Let's assume we want to edit a person (first/last name, birthday...) and we have a select menu to choose some friends (that are also persons here) @Stateful | @Scope(ScopeType.CONVERSATION) | @Name("personEditor") | public class PersonEditorBean implments PersonEditor { | | @In(required=false) @Out(required=false) | private Person person; | | @PersistenceContext(type=PersistenceContextType.EXTENDED) | private EntityManager em; | | @RequestParameter | private Long personId; | | @Begin | public String startEditing() { | person = em.find(Person.class, personId); | return "editorPage"; | } | | .... | } Now the editor page looks like that: ... | <h:selectManyMenu value="#{person.friends}" ... | Guess what? In this case there is NO LazyInitalisationException, though the person's getFriends() method is being called by JSF, what leads to a lazy fetching (I can see it in the logs, there's really no eager fetching). QUESTION: When accessing collections of seam components, why is there no LIE? Do those components remain managed? PS: When using normal (i.e. transaction scoped) persistence context instead of the extended one there are exceptions of course. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964975#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...