13 Replies Latest reply on Jul 25, 2007 3:01 PM by emsa

    How bad is unused conversations?

    emsa

      I have a menu system where the user selects tasks/pages, the menu system is shown on all pages so the user can select a new task/page at any time.

      Each selection creates a new Conversation - my concern is that this leaves a (possibly) huge amount of discarded Conversations around.

      Is this bad or how bad is this? Is there possibly a way to end the current Conversation (destroying any related Components at the end of the request) and starting a new Conversation for any new Conversational-scoped Components at the same time to avoid this situation?

      /Magnus

        • 1. Re: How bad is unused conversations?
          ellenzhao

          Is @Begin(join = true) what you are looking for?

          • 2. Re: How bad is unused conversations?
            emsa

            No - I might have dirty state in the Conversation that a want to get rid of. Also if the user selects the same page/task I want a new, empty, conversation.

            • 3. Re: How bad is unused conversations?
              gavin.king

              I think its not usually a big deal, just set a short conversation timeout (you can even reduce it using Conversation.instance().setTimeout()).

              But, you need to test performance in your own environment,

              • 4. Re: How bad is unused conversations?
                stephen.friedrich

                Hm, I'm not sure that I fully grok conversations, but it seems to me that starting conversations whenever a task/page is selected is overkill.

                Isn't it sufficient to start a conversation on the first submit after the page is shown ("the first task action")?

                • 5. Re: How bad is unused conversations?
                  jcg3

                  In your menu links, you should do something like this:

                  <s:link value="Visible Label"
                   view="/SomePage.xhtml" propagation="end" />


                  That will kill off the old conversation as the new one starts.

                  This is assuming that you can start the new conversation from the Seam component, or in your pages.xml config.

                  Play around with it and leverage the debug.seam page to see how conversations are created/destroyed as you use various propagation and conversation settings.

                  • 6. Re: How bad is unused conversations?
                    azalea

                    Hi

                    Gavin,
                    how do you think about controlling the number of the active conversations per user(session)?
                    That means that the old conversations will be destroyed when the number of the user's active conversations is beyond the maximum number of the conversations per user(session).

                    • 7. Re: How bad is unused conversations?
                      emsa

                      All very good suggestions and I have cycled through most of them in one way or another.

                      Hopefully Gavin is right and it will just work(tm) letting the Conversations timeout.

                      Starting the Conversation at "the first submit" might work in some cases but usually the state (lists of objects etc) is created when the page is first shown not when the first submit from that page occurs.

                      Using propagation="end" with any form of Conversation Begin in the same request/event will just reuse the same Conversation and not create a new one.

                      What I basically (think) I'm looking for is a propagation that ends a named/current conversation in a 'before phase', destroying it before doing anything else, and then promotes the new Conversation into a long-running one.

                      • 8. Re: How bad is unused conversations?
                        denis-karpov

                        Yes it is very important question.

                        now we have:
                        begin - marks current not long running conversation to be long running.
                        end - marks current long running conversation to be not long running.
                        join - join existing conversation (now it fails if there is no long running conversation, as I remember. Gavin promised to fix it ;-)
                        nest - begins nested conversation
                        none - leave the current long running conversation

                        But what if I want to start a new conversation no matter where I am now? Either I am in long running conversation or in not long running.
                        Like in this situation with menu bar. When I click menu item I want to start clean new long running conversation. In more strict words, to leave current conversation, to start new one (before render) and to mark a new one as long running.

                        (I am not sure is it possible now to leave one and start another new conversation inside one request?)

                        • 9. Re: How bad is unused conversations?
                          stephen.friedrich

                          To further complicate matters:
                          What one would sometimes want instead is to have a separate long-running conversation for each tab/menu/page, isn't that so?

                          User starts a task in one page then temporarily switches to another to look up needed information and likes to continue with the original tasks after that? Any idea?

                          • 10. Re: How bad is unused conversations?
                            emsa

                             

                            "stephen.friedrich" wrote:
                            To further complicate matters:
                            What one would sometimes want instead is to have a separate long-running conversation for each tab/menu/page, isn't that so?


                            This is pretty much covered by "explicit" conversation id (§6.6) and Workspace management (§6.7).

                            • 11. Re: How bad is unused conversations?
                              stephen.friedrich

                              Hm, I think explicit conversation ids only make sense when the application logic naturally suggests them. (Like using an article id for an article editor - it really makes no sense to edit the very same article in different conversations).

                              To make matters more concrete: Image a UI that shows a tabbed pane where each tab hosts a possible step of interactions.
                              So you want each tab to have a conversation of its own. However if you simply assign fixed conversation ids you will loose the ability to open new browser windows/tabs.

                              There's a lot of documentation how context demarcation technically works, but there is close to none how it it relates to interaction design.

                              Note that you would not have to think twice about how to implement this in a rich client: Each tab instance would simply holds its model which is "commited" at the final step of the task.

                              • 12. Re: How bad is unused conversations?
                                jcg3

                                Couldn't one use the conversationList object, inject it into your java class, and iterate through the conversations -- destroy'ing the ones that are no longer needed?

                                Not necessarily elegant, but if propagation="end" doesn't actually end the conversation, it seems like an alternative worth exploring.

                                • 13. Re: How bad is unused conversations?
                                  emsa

                                  Well you could use conversationList but how do you know what conversations are in use? The user could use several windows so many conversation could be active.

                                  The (only) way do solve this (if it really needs solving) is to extend s:link (or similar) with a new propagation, say, endAndBegin and one extra parameter, conversationIdToEnd.

                                  The server (probably SeamPhaseListener) will do exactly the same as with begin plus that it will set the timeout to 0 or promptly end the Conversation with the conversationIdToEnd.