This is probably a common question and I’ve been reading a lot about this, but I can’t look into a solution.
Let’s say I have an enterprise application in one glassfish server located in New York.
Then, my application grows very fast and I need another server with a loadbalancer.
Now my application is running in two different servers linked to a load balancer.
The problem, a very common problem I think, is this is acting like two completely different applications running in different servers, even if they have the same code.. both servers are acting completely different.
This leads to a concurrency problem in my database, since both servers are pointing to the same db.
For example , both servers at the same time (let’s suppose), try to update the same registry in the database, the first server will update a field (like “balance=10+1”) and the other server will do the same, the result will be balance=11 instead 12 because both got the original value at the same time.
What do you recommend for this issue?, we are using a Payara server instance and apparently payara has a hazelcast integration that may be a clue.
5
The same problems exist with a single server too. What if two users connected to the same server update the same balance at the same time? What if the same user opens two tabs in the browser, or two different browsers, or simply connects from two devices such as a PC and a smartphone, at the same time?
What happens more often that the application performs complex business operations within a transaction, but it also needs to preserve information through operations (in locally cache, in session variables, in static global variables, whatever). This is when you actually get an issue where an application which worked perfectly on a single server won’t work on a cluster of servers, because one server doesn’t necessarily know what data stored locally was invalidated by other servers. In those cases, applications should be redesigned to use distributed cache, and reverse proxy servers can be configured to use sticky sessions.
1