Good job,
But a clear job for AOP in JB4. The cache product is DYNAMITE.
marcf
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Sacha Labourey
> Sent: Sunday, November 23, 2003 6:17 PM
> To: [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: [JBoss-dev] Tomcat session replication
>
> 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 () has been added to
> JBoss-web.xml:
>
> 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:
>
> SET_AND_GET
> or
>
> SET_AND_NON_PRIMITIVE_GET n-replication-
> trigger>
> or
>
> SET
>
>
> 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
>
---
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
