It uses two tables, one that is used to define a unique id for each instance and the other is used to determine who the master is.
The tables are created by a single instance using a transaction that processes more than one sql statements.
Then each instance generates a unique id by executing the following sql statements.
step 1 - select id from karaf_node_id
step 2 - update karaf_node_id set id = curId + 1 where id = curId
step 3 - repeat step 1 if step was not successful else you have you unique id which is curId + 1
Then you try to get the master lock by using the following sql statement.
update karaf_lock set id = unique_id where id = 0 or id = unique_id
This statement is atomic and only a single instance will succeed removing the need to use transactions.
Note that there is more to this step than what is here but this is the enhance of it. The where id = unique_id
is not the complete story. Looking at the implementation will make it clearer.
I have added other mechanism that handles a heartbeat concept that allows other instance to try to become
a master if the row was not updated after a given amount of time. Note that this is dependent on the master
instance heartbeat rate and not on the slave instance heartbeat rate. This is the isAlive method.
The implementation deals with a master releasing the lock and it the master has a hard failure.
I will go ahead and cleanup the code with greater description detail on how this is used. As soon as
that has been done. I will attach the patch to this ticket.