Yes, the DeltaManager work as you describe. Only as set/removeAttribute
the changes was replicated, this
is an effective method that not all session attributes must be
replicated at every request. Currently this replication
method is the "quasi" standard at all cluster implementation that I have
used the last seven years. Inside the JBossCache AOP Framework you can
find first implementation
to fine grain replication objects.
(http://www.jboss.org/products/jbosscache). Let us know it works better
for you.
Peter
Ryan Heaton schrieb:
I'm trying to understand how the DeltaManager determines the deltas of a
session. From what I could find out by browsing the source code, there is no
way to know whether a session attribute is dirty unless is it "set" again, e.g.
HttpSession.setAttribute(Object obj). In other words, if the following piece of
servlet code were serviced within the context of a DeltaManager, I could not
expect the Count object to be broadcast to the cluster as a delta:
Count count = (Count) request.getSession().getAttribute("count");
count.value++;
I would have to ensure that the following code were executed in order to
broadcast the "count" attribute as a delta:
request.getSession().setAttribute("count", count);
1. Are my findings correct?
2. If my findings are correct, where is the justification for this logic? Is
there some specification or other official documentation that acknowledges that
this is acceptable?
Regards,
-Ryan Heaton
------------------------------------------------------------------------------
This message may contain confidential information, and is
intended only for the use of the individual(s) to whom it
is addressed.
------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
