Re: bug in JGStore

Davide Rossi wrote:

> Jules Gosnell wrote:
>
> Jules, thanks for your propmt reply.
>
> > 2). make a contract with the application that if they change an 
> > attributes value, they will call call session.setAttribute() and only 
> > replicate when you know the session is dirty - much more efficient, 
> > but does not handle change by reference - your problem.
>
>
> you mean that the whole session is marked as dirty whenever I call a 
> setAttribute or only the modified attribute (and its value)is propagated?

the Jetty DSM only replicates the changed attribute - essentially it 
replicates any mutating method invocation immediately to all other 
copies of the session.

> <...>
>
> > Of course, you can use various levels of checks and caching to 
> > mitigate the effect of the above, but I think these are the basic 
> > solutions to the problem.
> >
> > wadi.codehaus.org, my latest attempt to perfect the art of bomb-proof 
> > HttpSessions will provide both (1) and (2). The Jetty distributable 
> > session manager only provides (2). The best workaround for you is 
> > probably just to call s.setAttribute("X", s.getAttribute("X")) every 
> > time you know you have changed a session attribute value. This may 
> > add to the complexity of your code, but will give you a working 
> > solution.
> >
> > Does that help ?
>
>
> Well, I worked around the problem already (the issue was to realize 
> what cased the misfunctioning). I'm using session replication for a 
> research project. We are evaluating J2EE appservers with respect to 
> clustering with session replication at the web and at the ejb tier. 
> I'm curious to give wadi a look. For what I got by giving a fast look 
> to wadi's web pages it looks like you're using a filter to implement a 
> loadbalancer. We did the same here. We had to struggle against the 
> tons of bugs in the overbloated commons-httpclient before giving up 
> and using an in-house library. Anyway I'm definively interested in the 
> project.

interesting :-) My request proxying is not as finished as I would like - 
perhaps your impl is better ?

WADI can relocate requests to the node holding their session (currently 
disabled in cvs), or relocate the required session underneath the 
incoming request - migrating it to where it is needed ... so think of 
the load-balancing aspect of the filter as a last-ditch attempt to 
preserve session affinity when something has gone badly wrong and the 
enterprise strength lb above you has got it wrong. This happens when a 
node is shutdown and its sessions have to migrate elsewhere etc...

The current Jetty DSM was my second attempt at a decent distributable 
session manager. WADI will be my third. I have been talking to the 
OpenEJB guys about pushing WADI technology back into another library 
which they can share, so that SFSBs can migrate from one node to another 
when their host goes down for maintenance, or state needs to be 
rebalanced around the cluster. Ultimately I hope that this should form 
the basis of such fn-ality in all relevant clustered Geronimo services.

Subscribe to our lists - they are very low traffic. It would be good to 
have your input.

Jules

> Davide.


--
/**********************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
*    www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/




-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php