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 (<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</sessio
> n-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
> 



-------------------------------------------------------
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-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to