distributed atomic update

[muralivp]

I have a tomcat web app running on many servers in a farm all connected by a switch that routes incoming requests to the servers by picking a server in a round-robin fashion.

I have a servlet/jsp in my web application to trigger an action (say re-reading a disk file). This triggering obviously can happen in only one of the tomcat servers in the farm that the switch happened to pick if I invoke my servlet from a browser/HTTP client.

So the question is, how can I make this update happen simultaneously in all the instances of my webapp that are running on each one of the servers in the farm?

Can Spring JMX help accomplish this if I expose the Spring bean that performs this action as an MBean? or is the question simply absurd?

thanks

[Alarmnummer]

There are a lot of solutions possible.

You could use a database and lock the record before using it (select for update eg) or use the serialized isolation level (depending on the type of database, mvcc databases could throw an optimistic locking failure and maybe not what you want).

You could place a lock-file on the filesystem. If a node wants to read a file, it needs to place the lock file first. If this succeeds, it can read the file. If it doesn't succeed, you know that the file already is being read (or that the file was not removed after a reboot).

You could also use a distributed heap technique like Terracotta. The lock (ordinary java lock or a java.util.concurrent.Lock if you don't want to release the lock in the same scope as the acquire) can be distributed by terracotta so that it is shared over all nodes.

I don't have any additional info, but since most applications use a database, I would go for that solution.

[ikarzali]

Hi. Terracotta might be perfect for this use case (full disclosure: I am the CTO). But FWIW, Terracotta is OSS like Spring and the two are fully integrated. Anyways, the Terracotta cookbook will answer your question. Options include:

1. Distributed Methods where firing a method on one JVM will fire it on all. The re are no guarantees as to when the other JVMs will execute so this may or may not be appropriate:

http://www.terracotta.org/confluence...ipe?recipe=dmi

2. Straight synchronization as Alarmnummer mentioned:

http://www.terracotta.org/confluence...e=synchronized

3. CyclicBarrier from util.concurrent package in the JDK. All the JVMs have to come to the same point in code before proceeding...not exactly your use case:
http://www.terracotta.org/confluence...=cyclicbarrier

4. Classic listener pattern. Note that with Spring, you can just use Spring Events and Terracotta will fire those events cluster-wide:

http://www.terracotta.org/confluence...ecipe=listener

I recommend simple synchronization or Spring events.

Cheers,

--Ari