2 Replies Latest reply on Jan 6, 2012 6:16 PM by jovincen

    Long running conversation issue

    jovincen

      Hi All.


      I have a very particular issue in Seam. I don't believe it is common as I have not seen reference to it.


      Objects seem to be disappearing - for no good reason.


      I have a long running transaction - an editor. This editor composes objects together through various session scoped beans. One bean wraps a parent DB element. Other beans wrap various children rows. All these beans are driven from the primary editor.


      When I open the editor and complete the process quickly there are no problems - everything works as expected. However when I delay my inputs (by 10 minutes or so) I experience weirdness where an @Out variable looses field values that existed previously.


      The weird thing is that there are absolutely no problems if I do not delay inputs by 10 minutes.


      I have also noticed the strange behaviour. I have a property #{editor.selected.text} hooked up to a rich editor. Like so:


      @Stateful
      @Name("editor")
      public class Editor implements IEditor
      {

         private MyItem contrib;

         @In
         private ICache cache;


         public void Init()
         {
            cache.selectSomething();
            contrib = cache.getSelected();
         }

      ...

         public MyItem getSelected()
         {   
            return cache.getSelected();
         }

         public void done()
         {
         

           cache.done();

         }
      }

      <rich:editor ... value = "#{editor.getSelected}" />

      ...


      Now you can see that I keep a local reference to the variable in the second cache bean. When I complete the process quickly (call done early) both contrib and cache.getSelected() refer to the same object - the values posted by rich:editor appear in both.


      If I delay the post by 10 minutes (leave the machine when the rich:editor is displaying) When done is called then contrib and cache.getSelected() refer to separate objects. The value is posted to the cache.getSelected() only.


      My thoughts are that this has something to do with serialisation - beans should not directly reference objects owned by other beans (or hold them as copies only). However this would not explain the issue I am having with the @Out variable.


      I'm running:
      jboss-6.1.0.Final
      jboss-seam-2.2.2.Final


      I would really appreciate some suggestions!



      Cheers,
      Jon


        • 1. Re: Long running conversation issue
          mikkus70

          The fact that the problem presents itself after some minutes of inactivity leads to think that it is conversation-timeout related: conversations have a timeout, if you don't submit something, the conversation is stopped. This means that if you submit something after the timeout, you will be creating a new conversation (and hence recreating the components that were bound to that conversation). If you hold references to a conversation scoped component (or a property of a component) keep in mind that the object will be recreated if the conversation times out.


          The conversation timeout can be set in the <core:init/> element of components.xml, I think it defaults to 120000 milliseconds (2 minutes).


          It is generally a bad idea to hold references to a component or (worse yet) component properties. The idea with components is that the client of a component does not need to know how to deal with the component lifecycle. Keeping its data somewhere else is simply unnecessary, and can create this kind of problems. Why keep the selected item locally? You can as well maintain it in the cache component. Just inject the data directly:


          @In("#{cache.selected}") private transient MyItem contrib;
          

          • 2. Re: Long running conversation issue
            jovincen

            Thanks fir the advice!!


            Ive fixed the issue, by no longer directly storing the content of other beans. Also ons of my @out params also needed an @in.


            Id like to understand a bit more about what you mean directly referencing another component.