Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <0f1001c4a7c3$57f3bff0$dd01dc0a@Corp.LaQuinta.com>
From: "Filip Hanik - Dev" <devlists@hanik.com>
To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
References: <38A9EC5928D4D8498ECCBF14DF7C54440C0255@server02.hh.uptime.de>
Subject: Re: Synchronization in cluster
Date: Fri, 1 Oct 2004 09:31:30 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: 7bit

cause if you have two servers, two different sessions can perform upload in two different VMs.
He never said there is only one session doing upload, he was asking for a distributed lock

Filip

----- Original Message ----- 
From: "Ralph Einfeldt" <ralph.einfeldt@uptime-isc.de>
To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Sent: Friday, October 01, 2004 7:36 AM
Subject: RE: Synchronization in cluster


Why not ?

As I understood the static variable holds the information for the
current upload.

If the session is sticky the user will stay in the same jvm
and see the same static variable with each refresh.

I just see some downsides:
- if you want to assure that the downloads are serialised you have
  to implement a locking mechanism.
- you loose the central point to see all states at the same time.
- if the instance that performs the update dies, the user will 
  get to an instance that doesn't know anything about the download.

> -----Original Message-----
> From: Filip Hanik (lists) [mailto:devlists@hanik.com]
> Sent: Friday, October 01, 2004 1:51 PM
> To: Tomcat Users List
> Subject: RE: Synchronization in cluster
> 
> 
> That doesn't solve the problem
> 
> -----Original Message-----
> From: Ralph Einfeldt [mailto:ralph.einfeldt@uptime-isc.de]
> Sent: Friday, October 01, 2004 4:26 AM
> To: Tomcat Users List
> Subject: RE: Synchronization in cluster
> 
> 
> 
> With this usage scenario i would recommend sticky sessions.
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org