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 Tue, 10 Jul 2012 03:33:35 GMT

    [ https://issues.apache.org/jira/browse/KARAF-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410031#comment-13410031
] 

Claudio Corsi edited comment on KARAF-1572 at 7/10/12 3:32 AM:
---------------------------------------------------------------

Jamie and Christain,

Here is the work that I completed that uses a different mechanism to associate a master instance
given 2 or more karaf instances.  The new jdbc lock feature does not replace the original
version but was designed to offer another option to the users.  The main difference between
this version and the current one is that it does not open a long running transaction and it
only uses simple select, update and insert sql commands to manipulate the lock tables.   The
other change is that it does not use the FOR UPDATE syntax that is not available for all dbms.

I have not included any tests for this new feature but have tested this successfully using
the following dbms.

   - SQL Server
   - MySQL
   - Postgresql
   - Derby

I have not tried to test it against other dbms but all of the above successfully dealt with
a soft and hard failure of karaf.  The soft failure is the master karaf instance releasing
the lock while the hard failure is the master karaf instance crashing.  In both cases, a single
karaf instance of the remaining slaves acquired the lock and became the master.

Note that those tests did not involve starting a karaf instance but instead I created a simple
java application that followed the same sequences of calls that the karaf Main class does.
 I basically extracted those calls in a new class and used that one.  This allowed me to stop
and start multiple instances of the instances.

Feel free to look at the code and let me know if this seems to a be viable solution as an
addition to the current JDBC lock mechanism.

Note that the two classes include javadoc explaining how this works and what is expected from
the user.  Also note that the only difference between the current required properties and
this new version is that the new version requires the master instance lock_delay and does
not require a timeout value since we are not using a long running transaction. 

I last comment, this work was done against the 2.2.x branch which is currently the 2.2.9 snapshot.
                
      was (Author: ccorsi):
    Jamie and Christain,

Here is the work that I completed that uses a different mechanism to associate a master instance
given 2 or more karaf instances.  The new jdbc lock feature does not replace the original
version but was designed to offer another option to the users.  The main difference between
this version and the current one is that it does not open a long running transaction and it
only uses simple select, update and insert sql commands to manipulate the lock tables.   The
other change is that it does not use the FOR UPDATE syntax that is not available for all dbms.

I have not included any tests for this new feature but have tested this successfully using
the following dbms.

   - SQL Server
   - MySQL
   - Postgresql
   - Derby

I have not tried to test it against other dbms but all of the above successfully dealt with
a soft and hard failure of karaf.  The soft failure is the master karaf instance releasing
the lock while the hard failure is the master karaf instance crashing.  In both cases, a single
karaf instance of the remaining slaves acquired the lock and became the master.

Note that those tests did not involve starting a karaf instance but instead I created a simple
java application that followed the same sequences of calls that the karaf Main class does.
 I basically extracted those calls in a new class and used that one.  This allowed me to stop
and start multiple instances of the instances.

Feel free to look at the code and let me know if this seems to a be viable solution as an
addition to the current JDBC lock mechanism.

Note that the two classes include javadoc explaining how this works and what is expected from
the user.  Also note that the only difference between the current required properties and
this new version is that the new version requires the master instance lock_delay and does
not require a timeout value since we are not using a long running transaction. 
                  
> 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.1, 3.1.0
>
>         Attachments: GenericJDBCLock.patch
>
>
> 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