2 Replies Latest reply on May 16, 2007 11:08 PM by chubinator

    My Brain < Seam Conversations

    chubinator

      Hello,

      I'm really trying to get my arms around how the Seam conversations work and as soon as I think I understand it, I get some behavior that doesn't match my assumptions.

      Currently, I am struggling with the following:

      - I have a page we call a "Manager Overview". This page pulls in data from various tables into little summary "portlets" (fancy divs). One of these is a list of up-coming "Reminders".

      - The backing bean is a Stateful Session Bean, conversation scoped. It has an @Create method with an @Begin annotation to start a long running conversation. We do this to cache the data presented on the page while its being used.

      - The user can click the "Add" button to add a new reminder. This link calles a ReminderBean.add action method. This method is annotated with @Begin(nested=true).

      - The page for adding a reminder is displayed and has Cancel and Save buttons that call ReminderBean.cancel and ReminderBean.save respectively. Both of these methods are annotated with @End

      - The save method, before returning a String, does this: events.raiseTransactionSuccessEvent("REMINDER_UPDATED");

      - Back in the ManagerBean, we have the @Factory method for the Reminders also annotated with @Observer for the above event.

      - The cancel method, also annotated with @End just returns a string to redirect back to the calling page, in this case the manager overview.

      So, here's what I see:
      1. Browse to overview (manager.seam?cid=9)
      2. Click add to add a new reminder (editreminder.seam?cid=10&clr=true)
      3. Fill in data and click save (manager.seam?cid=10&parentConversationId=9)
      4. Newly added row appears in list and my log file indicates the observer method was called.
      5. Now I click add again (editreminder.seam?cid=11&clr=true)
      6. This time I click Cancel (manager.seam?cid=11&parentConversationId=9)
      7. Row that was added is now gone.

      I suspect its something to do with transactions and/or hibernate caching or perhaps just my poor usage of conversations.
      Is this even the right usage for conversations? i.e. using it to cache data and updating that data using @Observer from nested conversations?
      Any help/insight is greatly appreciated.

      Thanks,
      Mark

        • 1. Re: My Brain < Seam Conversations
          chubinator

          Thinking out loud:

          Could it be:

          1. After the save, Seam looks in the current context (the nested one) for the DataModel, doesn't see it and recreates it.

          2. Because the nested conversation is still valid through the end of the rendering of the manager page (after save is clicked), that its rendering with the nested conversation's version of the DataModel. So the new record appears.

          3. Then when I hit add again and then cancel, I've lost the first nested conversation and its conversation context DataModel.

          4. The parent conversation DataModel was never updated.

          The last part I'm assuming may be becuase of one of two things:
          1. Because the nested conversation datamodel variable was updated instead.

          2. and/or even though I've reloaded the data in my private member var, Seam doesn't know to invalidate the DataModel object its created on its behalf. i.e. I'm replacing the private member reference with a new one from the query result. Perhaps the DataModel variable in the parent conversation context is actually still referencing the old one?

          Or perhaps I'm overthinking all this.

          Really appreciate any help.

          Thanks,
          Mark

          • 2. Re: My Brain < Seam Conversations
            chubinator

             

            i.e. I'm replacing the private member reference with a new one from the query result. Perhaps the DataModel variable in the parent conversation context is actually still referencing the old one?


            That was it. I replaced my code with code that clears the list and adds the results instead and viola, it all works.

            Makes sense I guess as how else would seam know. Now my only concern is that for a moment, another datamodel context variable exists. I can likely resolve this using @End(beforeRedirect=true), right? that would (I think) force the nested conversation to finish before the actual redirect and the second (nested) DataModel won't get created.

            Anyhow, I'm in business again, although I think my subject text still applies :)