Bojan Dolinar [http://community.jboss.org/people/bodzolca] created the discussion "How to reconcile CMPC and SMPC?" To view the discussion, visit: http://community.jboss.org/message/611536#611536 -------------------------------------------------------------- When using EJB and Seam, it's probably inevitable to end up with lots of EJBs that are components at the same time, some with container-managed persistent context, some with SMPC. Because it was easier to do (mostly since it precludes any kind of LazyInitializationException) our codebase ended up with lots of EJBs/components with SMPC, even the ones that are part of the data engine and are not always part of the JSF lifecycle (triggered jobs, WS, other services, etc.). The absence of this lifecycle is probably the reason for some strange behaviour since it's not clear what the session is scoped to. For example, sometimes the actionqueue just doesn't get cleaned up after commit, so performance of a job degrades quickly (every flush "flushes" every preceding change), not to mention the memory leak. Migration from Seam 2.0.1 to 2.2.1 was the start of a whole new problem: org.hibernate.StaleStateException because optimistic locking failed. Looks like actionqueue again is keeping some stale objects and decides to commit them, quite sporadically, for all I could find out. I guess that in the absence of conversation the session doesn't get closed. The situation is alleviated by superseding SMPC with @PersistenceContext. But due to convoluted and numerous execution paths, I'm not allowed to even dream that I'm aware of all the side effects. LIE is just on the top of the list, because all the entities loaded by PC are detached sooner or later. All this leads to two questions. First, what would be the best way to handle this situation? Is mocking the approapriate JSF life cycle phases safe? Is it possible to scope SMPC to transaction programmatically? Second, what is the best way to handle this situation from the scratch, when you have that luxury? I didn't find anything addressing this exact problem and I'm sure I'm not the only one experiencing it. My personal approach would be to keep the seam layer as thin as possible. When I was not restricted by legacy code, it worked quite well, although I had to think carefully about LIE all over again. However, every book I've read so far advocates the exact opposite approach. Their samples are usually pure web applications, but I was more than welcome to the real world. Any thoughts or pointers to further reading on this would be appreciated. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/611536#611536] Start a new discussion in EJB3 at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]