karaf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claudio Corsi (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (KARAF-1572) Add SQL Server Support for JDBC Lock
Date Thu, 28 Jun 2012 17:28:46 GMT

    [ 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

        

Mime
View raw message