Hello,
A few changes in the Tomcat HTTP Session replication code.
First, some unnecessary synchronization has been removed. This should lead
to better scalability and in some cases remove the impression that the
replication is "hanging".
Second, the replication has been improved. Without using AOP-like
frameworks, it is hard to determine when an HTTP session is modified. When
setAttribute is called, the situation is (almost) obvious. However, if only
getAttribute is called, you never know as something like that could occur:
( (HashMap)session.getAttribute ("bla") ).put ("newKey",
"newValue");
In that case, the setAttribute is never called but the content of the
session is modified. Consequently, it is up to the developer to help the
container optimize its work.
A new tag (<session-replication-trigger>) has been added to JBoss-web.xml:
<!ELEMENT jboss-web (class-loading?, security-domain?, context-root?,
virtual-host?, use-session-cookies?, session-replication-trigger?,
resource-env-ref*,
resource-ref* , ejb-ref* , ejb-local-ref*, depends*)>
This tag determines when the container should consider that a session must
be replicated accross the cluster. Possible values are:
1 - "SET_AND_GET"
2 - "SET_AND_NON_PRIMITIVE_GET" (default value)
3 - "SET"
The first option is conservative but not optimal (performance-wise): it will
replicate the session even if its content has not been modified but simply
accessed (getAttribute). As shown above, there is no deterministic way to
know if the content of an attribute is not itself modified. It WAS the
default value in the past (simply because it was the only implementation
available), which explain why the perf will be improved now.
The second option is conservative but will only replicate if a non-primitive
Object has been accessed (Integer, Long, Double, Short, String, etc. which
are immutables). We can take that decision because the previous example
cannot be used to modify a session without calling setAttribute (as the
objects are immutable). It is the NEW default value.
The third option considers that the developer will explicitely call
setAttribute on the session otherwise it will not be automatically
replicated.
Tag examples:
<session-replication-trigger>SET_AND_GET</session-replication-trigger>
or
<session-replication-trigger>SET_AND_NON_PRIMITIVE_GET</session-replication-
trigger>
or
<session-replication-trigger>SET</session-replication-trigger>
Furthermore, in the past, when a new session was created, two replications
were occuring (one for the creation, one when setting the session). Now,
these two steps are reduce to a single step => a single replication.
These two changes should improve the performance of your current clustered
Web Application (using Tomcat).
Cheers,
Sacha
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
