0 Replies Latest reply on Sep 29, 2008 9:20 AM by Troy Tarrrant

    Storing large entity list on conversation bad!

    Troy Tarrrant Newbie


      I have this app where I need to query up front and retrieve a largish (1000) set of entities and keep them in the conversation whilst each (ajax) request processes filters and the like over them as well as other ajax requests that go nowhere near the result list.

      I do this by storing a List of MyEntity as a private member in the POJO that is scoped to the CONVERSATION.

      A simple design, but agreed not the most elegant, I would have thought that this would have been fine (apart from memory of storing the largish result set - which I am prepared to live with given the app) however ALL of my ajax requests degrade significantly when the result set exists vs. when the result doesn't exist.

      Now if I have an ajax request that does nothing on the server other than a round trip then I can process this easily in under 100ms. If I load the conversation up with a 1000 MyEntity objects in the List and just leave them there the same request that does nothing other than a round trip now takes over 2secs to process. The request doesn't do anything and the entities just sit there doing nothing (no rendering) so I was really surprised.

      I changed the scope of the POJO to SESSION and loaded it up again with 1000 entities and my round trip returns to under 100ms again.

      Intrigued I switched back to CONVERSATION and loaded up my large 1000 object result set with DTO's and observed my round trip again performing at under 100ms.

      So it seems that largish entities sitting dormant in the CONVERSATION scope consume a lot of time in the framework.

      Not satisfied I starting trolling through server logs and found that all the extra time is consumed in the RENDER RESPONSE phase - event though the entities are not rendered at all.

      Turning on seam debug in the logs I get over a 1000 entries of the following

      2008-09-29 19:01:45,026 DEBUG [org.jboss.seam.util.Naming] JNDI InitialContext properties:{java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory, java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces}
      2008-09-29 19:01:45,034 DEBUG [org.jboss.seam.contexts.Contexts] found in conversation context: org.jboss.seam.persistence.persistenceContexts
      2008-09-29 19:01:45,034 DEBUG [org.jboss.seam.contexts.Contexts] found in conversation context: entityManager

      All this comes under:

      2008-09-29 19:01:45,024 DEBUG [org.jboss.seam.contexts.Contexts] flushing server-side conversation context

      Now this takes the total round trip processing from 100ms to over 2000ms - a 20 times degradation in performance.

      Further investigation sees seam passivating each entity even if it has not been used as it clears up the contexts.

      This leads me to a different design, obviously use the SESSION (which I don't want to do) or read the entities once and convert them into DTO POJO's and take the 2sec hit only once. Either way it's not nice.

      Can anybody shed some light on this? and perhaps suggest a better design (and I really do need to keep the 1000 objects in the CONVERSATION) like using some setting in Seam that I don't know about?

      Thanks in advance