9 Replies Latest reply on Jul 16, 2007 3:35 PM by Moshe Immerman

    Singe Page Application and Conversations

    Moshe Immerman Newbie

      I have an application that is composed of a single page with many different views and popup actions executed via ajax. I am currently using a long-running conversation per page. The page can be open for hours at a time so one conversation can last 4h+ with many different unrelated popup-actions executed in the same conversation. I believe this is not the best way of using conversations. What would be better for my use case?

        • 1. Re: Singe Page Application and Conversations
          Shane Bryzak Master

          There's not enough information to give a definitive answer, but in general if you are executing unrelated actions then these should not be within the scope of the same conversation. I don't know if you're using Seam Remoting, but if you are then you have control over which conversation your AJAX requests participate in. I can't really recommend anything more than this without having more information.

          • 2. Re: Singe Page Application and Conversations
            Moshe Immerman Newbie

            I am using IceFaces.

            Is there anything wrong with keeping one long conversation running for the page and a nested conversation for each separate action .

            Is there anything i have to take into account when a conversation is active for hours on end?


            • 3. Re: Singe Page Application and Conversations
              Gavin King Master

              The problem with extremely long-running conversations in Seam is that Seam-managed persistence contexts are bound to the conversation, and will fill up with stale data.

              It is *possible* to futz with stuff to get a PC-per-nested-conversation, but it wouldn't be that transparent.

              If you're not using Seam-managed PCs, what you are doing would be OK.

              A possible solution is to have "per-action" state in a per-nested-conversation SFSB, with an extended persistence context bound to the SFSB. ie. @PersistenceContext(type=EXTENDED)

              Actually I think that's a good way to do it :-)

              • 4. Re: Singe Page Application and Conversations
                Moshe Immerman Newbie

                The problem I have is that the parent conversation has an object (selectedDocument) which almost always gets updated by the nested action. If I were to use a 'per-action' state is there any simple way of updating the object in the parent conversation?

                I would prefer to keep using the SMPC as it makes my code so much cleaner :)

                The only significant amount of stale data would come from old selectedDocument's, is there any way to manually evict them?

                on a side note, what is the recommended way for recovering from a transaction roll-back, At the moment I have lots of:

                if (!em.contains(entity))
                 entity = em.find(Entity.class, entity.getId)


                scattered around, which does not seem to be the most elegant solution.

                I have tried outjecting the id's and then reloading them in @Create and having an ErrorHandler which does:
                 ejbContext.setRollBackOnly();
                Contexts.removeFromAllContexts("seamComp")


                but it doesn't seam to work as expected. Will the transaction always rollback before the next render phase?






                • 5. Re: Singe Page Application and Conversations
                  Gavin King Master

                  OK, I really think you're doing Bad Stuff here.

                  (1) never try to have a managed entity / persistence context around for more than a single optimistic transaction. If you try to have a managed entity sitting there for an indefinite period of time, you will get into lots of problems when other users update data underneath you.

                  (2) when a tx fails, you MUST throw away the PC and start again - that is the rule of PCs.

                  • 6. Re: Singe Page Application and Conversations
                    Moshe Immerman Newbie

                    thanks for your quick reply.

                    1)In the long running conversation, there are no updates taking place - The information is only read for rendering, updates take place in the nested actions. What should I do instead?

                    2) doesn't rolling back the transaction destroy the PC?

                    start again

                    that is what I am trying to do, re-load all my previous entities using their id's into the new PC

                    • 7. Re: Singe Page Application and Conversations
                      Gavin King Master

                      1) The PC is a cache of data that is NOT kept consistent with the database, except by optimistic locking. You should use a new PC each time you render.

                      2) Nope, it just leaves it in a "dead" state.

                      • 8. Re: Singe Page Application and Conversations
                        Moshe Immerman Newbie

                        ok - where would I start and end my conversation?






                        • 9. Re: Singe Page Application and Conversations
                          Moshe Immerman Newbie

                          gavin, thanks for all your patience so far ;)

                          Lets start again ...

                          my page = state (mostly selections) + view
                          interactions on the page update the state
                          interactions in actions update the view

                          1) How should I get a new PC (SMPC or PC) per render?

                          2) Should I store my state (selected Id or selected entity) in a Session Context or a Long Running Conversation (with no PC) ?

                          3) How should I re-attach my selected items before the render? - Is a PhaseListener the best way of doing it?