How can I flag HTTP session attributes to not be replicated ?

Question

          WLS 5.1 SP8 - In memory replication of a stateful servlet. Is
          there any way to flag data that has been, or is being, loaded into
          a HTTP session so as to not be replicated ? It's a long story,
          but we have some data loaded into a hashtable, more specifically
          a Properties object, stored in our session. With the hastable
          already loaded into the HTTP session, weblogic does not detect
          when we add values to the table, and therefore does not replicate
          the changes. Which is ok since WLS is working as designed. To
          get around this we load the hashtable back into the session everytime
          we add a value to the hashtable. Yup, I know that's ugly. Anyway,
          what I'm trying to find out if is there is an attribute that we
          can set to indicate, to not replicate this data or that data.
          Something along the lines of a attribute on a per hastable value
          basis. For example, I load value A into my hashtable, then I
          need to put my hashtable into the session to get it replicated.
          Next I load value B into the hastable, and again to get it replicated
          I have to load the entire hashtable back into the session. The
          problem here is that the entire table gets replciated. Does anyone
          know if I can set an attribute on value A, when I'm adding value
          B, so as to not replicate value A when I reload the table ? Of
          course all goal is to not store so much data in the session, but
          I'm trying to find a work around until that is completed.
          Thanks,
          David
          

Answer 1

          Where can I find documentation on the details of how Weblogic decides what will
          be replicated in the HTTPSession object (for example, it only replicates attributes
          which are set or updated using "setAttribute()"?
          Prasad Peddada <[email protected]> wrote:
          >Robert,
          >
          > It is true that we replicate only when you call setAttribute in case
          >of servlets.
          >
          >In case of EJB it is slightly different. EJB sends diff's across the
          >wire. It doesn't
          >replicate the entire state with every request.
          >
          >-- Prasad
          >
          >Chris Palmer wrote:
          >
          >> I think Viresh was referring to modifying part of one attribute causing
          >the whole
          >> of that attribute (i.e. the hashtable) to be replicated.
          >>
          >> Is it actually true though that the behaviour would be different in
          >a stateful
          >> session EJB? I had assumed that the WHOLE ejb state would be replicated
          >each time
          >> (i.e. after each invocation), without even the benefit of having a
          >mechanism such
          >> as setAttribute() to flag the attributes that had changed...
          >>
          >> Chris
          >>
          >> Robert Patrick wrote:
          >>
          >> ? Huh? Since when does it always replicate the entire HttpSession?
          > We were
          >> ? told that it uses a hook in the setAttribute() call to determine
          >which
          >> ? attributes have changed and only replicates those attributes. I
          >know this to
          >> ? be the case because if I retrieve a previously stored attribute from
          >the
          >> ? HttpSession and modify it, my changes do not get replicated unless
          >I call
          >> ? setAttribute again...
          >> ?
          >> ? Robert
          >> ?
          >> ? Viresh Garg wrote:
          >> ?
          >> ? ? Servlet sessions don't work on diffs, so no matter what you do,
          >entire
          >> ? ? Hashtable will be replicated. If you want the optimization for
          >only
          >> ? ? replicating the diff ( the stuff that has changed between 2 updates)
          >,
          >> ? ? consider using stateful session bean and having hashtable part
          >of
          >> ? ? conversational state of stateful session bean.
          >> ? ?
          >> ? ? The solution that you suggested on your own for your problem is
          >not ugly
          >> ? ? as the same solution is used by many customers that I know of.
          >This is
          >> ? ? particularly a problem for people that use Java Beans and use the
          >set
          >> ? ? Property directive of Java Bean in JSP. There also in our auto
          >generated
          >> ? ? code, we put the JavaBean back in HTTP Session, when a setter is
          >called to
          >> ? ? enforce replication.
          >> ? ?
          >> ? ? Keep in mind that whatever we do for replication, we want to support
          >it
          >> ? ? using ONLY standard servlet API and we don't want to introduce
          >any WLS
          >> ? ? specific API to achieve this, and so putting value back in session
          >is the
          >> ? ? only way.
          >> ? ?
          >> ? ? Viresh Garg
          >> ? ? Principal Developer Relations Engineer
          >> ? ? BEA Systems
          >> ? ?
          >> ? ? Dave Javu wrote:
          >> ? ?
          >> ? ? ? WLS 5.1 SP8 - In memory replication of a stateful servlet.
          >Is
          >> ? ? ? there any way to flag data that has been, or is being, loaded
          >into
          >> ? ? ? a HTTP session so as to not be replicated ? It's a long story,
          >> ? ? ? but we have some data loaded into a hashtable, more specifically
          >> ? ? ? a Properties object, stored in our session. With the hastable
          >> ? ? ? already loaded into the HTTP session, weblogic does not detect
          >> ? ? ? when we add values to the table, and therefore does not replicate
          >> ? ? ? the changes. Which is ok since WLS is working as designed.
          >To
          >> ? ? ? get around this we load the hashtable back into the session everytime
          >> ? ? ? we add a value to the hashtable. Yup, I know that's ugly.
          >Anyway,
          >> ? ? ? what I'm trying to find out if is there is an attribute that
          >we
          >> ? ? ? can set to indicate, to not replicate this data or that data.
          >> ? ? ? Something along the lines of a attribute on a per hastable value
          >> ? ? ? basis. For example, I load value A into my hashtable, then
          >I
          >> ? ? ? need to put my hashtable into the session to get it replicated.
          >> ? ? ? Next I load value B into the hastable, and again to get it replicated
          >> ? ? ? I have to load the entire hashtable back into the session. The
          >> ? ? ? problem here is that the entire table gets replciated. Does
          >anyone
          >> ? ? ? know if I can set an attribute on value A, when I'm adding value
          >> ? ? ? B, so as to not replicate value A when I reload the table ?
          >Of
          >> ? ? ? course all goal is to not store so much data in the session,
          >but
          >> ? ? ? I'm trying to find a work around until that is completed.
          >> ? ? ? Thanks,
          >> ? ? ? David
          >