While looking at load balancer options I was trying to see if the non session
sticky mode was an option. Obviously there are a bunch of issues I hadn't
considered such as threading mode and concurrent client access. It is clear
I will stick with the original plan of session sticky mode. 

-mike


Johan Compagner wrote:
> 
> Why don't you want session sticky load balancing?
> 
> How does none sticky sessions work then? If there are 2 request comming in
> then wicket makes sure
> that the page is access in one thread. So that the page is not changed by
> 2
> threads at the same time
> Does your application server lock over the nodes when there are 2 or more
> request comming in from the same client?
> If not how does it then sync up again? How does it "merge" the pages?
> 
> johan
> 
> 
> 
> On 9/28/07, mchack <[EMAIL PROTECTED]> wrote:
>>
>>
>> I am deploying my application in a clustered environment. Eliminating
>> session
>> sticky load balancing would be an advantage for me. Session data is
>> already
>> replicated in a clustered environment. Are the mechanics in place to
>> share
>> the Page Cache with other machines if I use a clustered file system that
>> allows concurrent access in this way providing non sticky LB across the
>> cluster?
>>
>> -Mike
>> --
>> View this message in context:
>> http://www.nabble.com/Clustering-Question---Can-the-2nd-Level-Page-Cache-be-shared-in-a-clustered-filesystem-configuration--tf4531607.html#a12932067
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Clustering-Question---Can-the-2nd-Level-Page-Cache-be-shared-in-a-clustered-filesystem-configuration--tf4531607.html#a12937318
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to