Ask Questions and Find Answers

5.2.3, wow, that's got some age on it...


There's not going to be a cross-node lock mechanism, but you might try building out on the Liferay Message Bus. I believe, even at that time, the LMB had cluster support and would synchronize message processing.

This way, the Post and Debit messages would go into the LMB and queue up, and the message listener would process them in order, assuring the correct outcome.  If the changes are applying to Liferay entities generated by ServiceBuilder, the updates will broadcast cache change messages to all nodes so they ditch the stale values and show the updated values persisted by the message listener.

If you are not using any Liferay facilities, I think you'll find your task is hard in general. If you have two nodes competing for a lock, they can be in a race to see who gets it first. You need an outside entity to manage the lock otherwise the node that manages it can starve out the node that doesn't. You'll face issues such as what happens if a node crashes while holding the lock, the lock manager crashes, cluster-wide notification so other nodes are aware of data value changes (not a problem if you never cache the retrieved value for the account), etc.

None of these issues are specific to Liferay, of course. Liferay has some built in mechanisms to help in these kinds of situations because they are things that Liferay has faced, but if you're not building off of Liferay tools and APIs those facilities may not be available to you.

How to implement Lock mechanism in Multiple node Environment

If you're using Hibernate, you could use its multi-version concurrency control mechanism, where it uses a column that contains the version of the record, and essentially adds "set versionColumn = currentVersionValue + 1 where versionColumn = currentVersionValue" to the update clause. This causes the update to fail if something has already updated the row (since the versionColumn will be different), and it's something that comes built into Service Builder in later Liferay releases.

If you're not using Hibernate, another strategy is to force all of the updates to happen on a single node, which allows you to continue using the approach you have for a single node environment. You'll basically be writing all of the node coordination logic yourself though, because none of the stuff Liferay now has to help you out with this exists in 5.2.x.

You need to implement a locking strategy like optimistic locking or pessimistic locking. Which one is better for you, depends on your exact usecase.
https://enterprisecraftsmanship.com/2017/09/18/optimistic-locking-automatic-retry/
Implementing optimistic locking in Liferay 6 was possible, but annoying. I think, this post describes how to do it (I tried it once).
https://zenidas.wordpress.com/recipes/optimistic-locking-in-liferay/
I have no idea if that works in 5.2. But it should hint you in the right direction.