[
https://issues.apache.org/jira/browse/KARAF-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403250#comment-13403250
]
Claudio Corsi edited comment on KARAF-1572 at 6/28/12 5:28 PM:
---------------------------------------------------------------
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.
was (Author: ccorsi):
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.
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.
> Add SQL Server Support for JDBC Lock
> -------------------------------------
>
> Key: KARAF-1572
> URL: https://issues.apache.org/jira/browse/KARAF-1572
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-instance
> Affects Versions: 2.2.7
> Reporter: Claudio Corsi
> Fix For: 2.2.9, 2.3.0, 3.1.0
>
>
> The current JDBCLock implementations do not work when using Microsoft SQL
> Server since this requires that you use a CURSOR with the SELECT statement.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
