Hi, I have a SFSB: @Stateful | @Scope(ScopeType.CONVERSATION) using an extended persistence context. I also enabled manual flush mode at the beginning on of the conversation. @PersistenceContext(unitName="mypu", | type=PersistenceContextType.EXTENDED) | private EntityManager em; @Begin(flushMode = FlushModeType.MANUAL) During the conversation some calls are made to a DAO Service implemented as a SLSB. @Stateless | @Scope(ScopeType.SESSION) This SLSB gets an entitymanager through this annotation: @PersistenceContext(unitName=RDMConstants.RDM_PERSISTENCE_UNIT_NAME) | private EntityManager em; I am using CMT transactions with the default setting (which is transaction.REQUIRED) for both EJBs The SLSB issues calls to em.merge(), em.remove(), etc.. However I noticed that the em is flushed as soon as the system transaction commits which is when we return from the SFSB method execution. Even though each EJBs have it's own EM instance they are both using the same persistence context, would it be possible to inherit the flush mode set on the SFSB in the SLSB ? Right now the SLSB inherits the persistence context bound to the system transaction. I am doing all this because I want to push all EM related operation to SLSBs and allow better re-usability. How can I achieve this with a manual flush mode ? I want to prevent automatic flush the end of every request. I also want to avoid hardcoding the SLSB to use a specific flush mode strategy. One possible solution would be to never call the SLSB (EM methods) until the @End of the conversation. The SFSB would queue all pending updates in custom memory structures (List, Maps, etc..). These structures would be used to send all requests to the SLSB inside the method marked with @End annotation. Alternatively I could do all EM operations inside the SFSB throughout the conversation and only em.flush() at the @End of the conversation, but then I would lose some re-usability because I cannot do EM operations in the SLSBs without seeing them committed at the end of the system transaction. I hope I explained my usecase clear enough. What is the best practice in this scenario ? It seems that SEAM promotes a 1 layer approach where both business logic and persistence logic would sit inside the same SFSB. Please correct me if i'm wrong. Thanks, -Guillaume View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127992#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...