Am 06.04.2011 um 22:35 schrieb André Warnier: > Jürgen Jakobitsch wrote: > ... >> >> image you have a simple text file in the WEB-INF directory of a webapp named >> ClusterApp. this ClusterApp is deployed >> on three tomcats in a cluster. now comes a POST request, that updates the >> text file (adds one line to it). >> now of course i need to synchronize the text file on all tomcats in the >> cluster. >> > Ok, let's imagine there are initially 3 identical simple text files, on each > of the 3 tomcats. > And there are 2 clients accessing the load balancer. > In order to determine if they need to update the text file, the clients first > request the > text file to examine it. Their requests go to 2 different tomcats via the > load-balancer. > But it does not matter, since they both get the same response text file, > since it is > identical. > Now client A decides to update the file by adding a line XXX to it. > And client B decides to update the file by adding a line YYY to it. > They both POST their request at about the same time to the front-end, and the > front-end > (or whatever replication mechanism) sends each request to all 3 back-end > tomcats. > When the 2 POST requests have been processed, what is the state of the 3 text > files ? >
I would say this is a classical case for either centralized datastore or distributed transaction manager. To solve the issue with the existing setup, I would possibly serialize the write request into a message queue that has one subscriber per cluster member. Only the subscriber thread is allowed to write into the file. A little bit tuning the queue setup will provide you with a fail safe system, were a crashing cluster member will recover and continue on his copies of the write requests. Overall the files should be reasonable equal. If you need realtime updates of all cluster members, the datastore you have chosen IMHO sucks :-) I suppose you would need to add a kind of distributed transaction then. This could be reached if you send a commit message to all cluster members when you have successfully written your data. For each dataset, you expect a commit message from all others before you serve it to clients again... sounds a little bit like reinventing the wheel. Regards, Thomas > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
