3 Replies Latest reply on Oct 2, 2009 7:58 AM by surfingspider

    Seam Conversation Scenario- Doubt

      I read the user guide of seam which mentions the following points about the conversation model:





      1.The @Begin annotation specifies that the annotated method begins a long-running conversation, so the current conversation context will not be destroyed at the end of the request. Instead, it will be reassociated with every request from the current window, and destroyed either by timeout due to conversation inactivity or invocation of a matching @End method.                                                                                  
      
      
      2. The @End annotation specifies that the annotated method ends the current long-running conversation, so the current conversation context will be destroyed at the end of the request.



      So lets say when a user comes to a page (The conversation starts here:@Begin method called) he performs some action on page but suddenly changes his mind and without pressing the submit or save button leaves that page and starts browsing other pages of application, which means the @end method is not called yet.


      Does that mean that conversation is still active to all the subsequent requests ?? 
      In this case what are the implications ?



        • 1. Re: Seam Conversation Scenario- Doubt
          brandonsimpson

          I had the same concerns once I found out how conversations work. Unfortunately, I think you are dead on. If you have any sort of global links that appear on each page and you don't want components or the persistence context to leak onto other pages, you have to somehow start a new conversation before navigating to the new page. I think merely ending the current conversation won't work, because that just demotes the conversation back to a temporary one...and that temporary one will still be present when you navigate and render the next page as far as I know. I haven't had time to play around with this much, so I don't have a good solution, but sadly, I think the only alternative is starting a new conversation, which means you will lose any FacesMessages or other stuff you do want to pass to the next page. It would be nice if there was an easy way to start a new conversation with a new entityManager but still get your FacesMessages or other things you selectively did want to carry over. I think it's probably doable with some coding, but it would be nice if the functionality was there out of the box, easy to use, and by default. If anyone solves this, please share.


          It's really a bad problem imo. You can have persistent objects that the user made changes to but didn't submit (instead they just navigate elsewhere). Then on some other seemingly unrelated page where they persist something else, you're going to have those changes persisted as well. The only other thing I came up with was to have more than one entityManager...one where you are holding the changes the user might want to make. And another that you merge the changes that they commited to into and then persist. I haven't tried it myself, but I'm a little curious about how multiple entityManagers will play with each other. Anyway, good luck!

          • 2. Re: Seam Conversation Scenario- Doubt
            kukeltje.ronald.jbpm.org

            Depends on how the rest of the navigation is implemented... it is indeed not ended by default so you can always return to it (within the time-out period)


            • 3. Re: Seam Conversation Scenario- Doubt
              surfingspider

              Spring WebFlow also has this 'problem' for global navigation. As long as their is some kind of conversation model, or one that can support multiple concurrent conversations, then the framework arbitrarily ending one is probably less programmer friendly than keeping it alive. The option you have is to have the global navigation hit some bean which KIA's the conversation it is leaving from.