2 Replies Latest reply on Nov 10, 2011 9:57 AM by bodzolca

    How to reconcile CMPC and SMPC?

    bodzolca

      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.

        • 1. Re: How to reconcile CMPC and SMPC?
          jaikiran

          This looks more like a Seam question which might get some answers in the Seam forum http://seamframework.org/Community/SeamUsers.

           

          Having said that, could you provide a bit more details including any relevant code and any configs or exceptions that'll better explain what's going on? If it turns out something related to how EJB3 works then maybe we can help.

          • 2. Re: How to reconcile CMPC and SMPC?
            bodzolca

            Thx for answering and sorry for not responding back, but in the meantime we thought of a solution that is good enough. For common methods we're using static methods in POJOs that are passed a session. In this way web layer just passes SMPC and other code CMPC. It just amazes me that this problem is not discussed already. It should be common enough.