Need a locking a mechanism (Persistent lock) which will not be lost even if application restarts?

I have the following scenario. There are 2 applications that share a database. Both these applications can be used to alter the underlying database. For e.g., Customer 1 can be modified from both the systems. I want to make sure when someone performs an action on say customer 1 in application 1 then I need a persistent lock for that lock so that nobody from application 2 can perform any action on the same customer. Even if any of these applications go down, it should still hold the lock. What will be the right approach for solving such an issue?

As @Turing85's comment hints at, this is extremely dangerous territory: If someone trips over a power cable, your app is out of the running and cannot be started again. permanently. At least, until someone goes in and manually addresses the problem. This is rarely what you want.

The normal solution is to do the locking at the DB level: If it is a 'single file is the database' model, such as H2 or SQLite, then let the DB engine lock the file for writing, and treat the OS-level file lock serve as your gating mechanism. This has the considerable advantage that if app A falls out of the air for any reason (power shortage, hard crash, who knows), the lock is relinquished.

If the DB is a separate running process (psql, mysql, mssql, etc), those have locking features you can use.

If none of those options are available, you can handroll it: You can make files with the new file API that are guaranteed atomic/unique:

int pid = 0; // see below
Path p = Paths.get("/absolute/path/to/agreed/upon/lockfile/location/lockfile.pid");
Files.write(p, String.valueOf(pid), StandardOpenOption.CREATE_NEW);

The CREATE_NEW open option is asking java to ensure atomicity: Either [A] the file did not exist before, exists now, and it is this process that made it, or [B] this will throw.

There is no [C] this process created it, but another process unluckily was doing the same thing at the same time and also created it and one of these processes is now overwriting the efforts of the other - that is what CREATE_NEW means and guarantees: That this won't happen. (vs the CREATE option which will overwrite what's there and makes no atomicity guarantees).

You can now use the file system as your global unique lock: To acquire the lock, you make that file. If you can, great. You got it. If you can't, then you have to wait (you'll need to use the watcher API or a loop if you care about acquiring it as soon as you can, not a great option, that is a very expensive operation compared to in-process locking!) - to relinquish the lock, simply delete the file.

To guard against a hardcrash leaving the file there, stuck, permanently, preventing your app from ever running again, it can help to register the 'pid' (process id) inside it. This gives you some debugging if you are manually fixing matters, and you can use to automatically check ('hey, OS, is there even still a process running with id 123981? No? Okay, then it must have hard-crashed and left the lock file in place!'). Unfortunately, working with pids in java is convoluted, as java is more or less designed around the notion that you shouldn't rely too much on the underlying OS, and java does not really assume that 'process IDs' are a thing the underlying OS does. google around for how to obtain it, you CAN do this.

Which gets us to the final point, your evident fear of inconsistency: After all, you actually appear to the desire the clearly insane notion that you want the app to be permanently disabled when there's a hard crash (a process crashes and the lock is not explicitly relinquished). I assume you want this because you are afraid that the database is left in an inconsistent state and you don't want anything to ever touch it again until you manually look at it.

Oookay, well, the lock file business is precisely how you get that. However, this is rather user hostile, and not needed: You can design databases and process flows (using transactions, append-only tables, and journal systems) so that they will always cleanly survive hard crashes.

For example, consider file systems. In ye old aged sepia toned past, when you stumbled over your power cord, then on bootup you'd get a nasty thing where the system would do a 'full disk check', and it may well find a bunch of errors.

But on modern systems this is no longer the case. Trip over that power card all day long. You won't get corrupted files (unless processes are badly designed, in which case the corruption is the fault of the app, not the file system), and no extensive disk checks are needed.

This works primarily by a concept known as 'journalling'.

Say, you want to replace a file that reads "Hello, World!" with the text "Goodbye now!". You could just start writing bytes. Let's say you get to "Goodb, World!" and then someone trips over a cable.

You're now hosed. The data is inconsistent and who knows what was happening.

But imagine a different system:

Journalling

The system first makes a file called '.jobrecord', writes in it: I'm going to open this file, and overwrite the data at the start with 'Goodbye, now!'.

Then, it actually goes ahead and does that.

Then, it deletes the job record in an atomic way (by updating a single byte for example, to mark: "done").

Now, on bootup, the system can check if that file is there, and if it is, check that the job was actually done, or finish it if need be. Voila, now you can never have an inconsistent system.

You can write such tools too.

Alternative: append-only

Another way to roll is that data is only ever added, and has a validity marker. So, you never overwrite any files, you only make new ones, and you 'rotate them into place'. For example, instead of writing over the file, you make a new file called 'target.new', copy over the data, then overwrite the start with "Goodbye, now!", and then atomically rename the file over the original 'target', thus guaranteeing that the original is never harmed, and in one moment in time, the 'view' of the target file is the old one, and in another atomic followup moment, the new one, with never a time in between that is halfway between two points.

A similar concept in databases is to never UPDATE, only INSERT, having an atomically increasing counter, and knowing that 'the current state' is always the row with the highest counter number.

The point is: There are ways to build robust systems that do not ever result in data being inconsistent unless an external force corrupts your data stores.