[jira] [Commented] (ASTERIXDB-2522) Skip logging WAIT record during lock conflicts

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

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

ASF subversion and git services commented on ASTERIXDB-2522:
------------------------------------------------------------

Commit e060d5cfe8138339475a4ac69e38154e81eaa553 in asterixdb's branch refs/heads/master from luochen
[ https://gitbox.apache.org/repos/asf?p=asterixdb.git;h=e060d5c ]

[ASTERIXDB-2522][TX] Skip WAIT record during lock conflicts

- user model changes: no
- storage format changes: no
- interface changes: no

Details:
- A small optimization to our deadlock-free locking potocol by skipping
the WAIT record. Once the partial frame has been flushed and previous
records are committed, the locks held by the write thread will
eventually be released by the log flusher thread. There is no need to
force the writer thread to wait for the log flusher thread.

Change-Id: I6ef3979d6393d45a6b7b2eb5f09f147299b5cd9f
Reviewed-on: https://asterix-gerrit.ics.uci.edu/3232
Sonar-Qube: Jenkins <je...@fulliautomatix.ics.uci.edu>
Tested-by: Jenkins <je...@fulliautomatix.ics.uci.edu>
Contrib: Jenkins <je...@fulliautomatix.ics.uci.edu>
Integration-Tests: Jenkins <je...@fulliautomatix.ics.uci.edu>
Reviewed-by: Murtadha Hubail <mh...@apache.org>


> Skip logging WAIT record during lock conflicts
> ----------------------------------------------
>
>                 Key: ASTERIXDB-2522
>                 URL: https://issues.apache.org/jira/browse/ASTERIXDB-2522
>             Project: Apache AsterixDB
>          Issue Type: Improvement
>          Components: TX - Transactions
>            Reporter: Chen Luo
>            Assignee: Chen Luo
>            Priority: Minor
>
> Currently, our deadlock-free locking protocol (https://cwiki.apache.org/confluence/display/ASTERIXDB/Deadlock-Free+Locking+Protocol) is conservative. It works as follows:
> A writer thread (i.e., transactor) first tries to acquire X lock on a primary key.
> If the try lock fails, it should release all previous held locks before acquiring the X lock. To release previous locks, the transactor pushes partial frames so that previous records can be committed, and further log a WAIT record to wait for the log flusher to force all previous log records and unlock previous locks.
> However, the WAIT record is actually not necessary. After committing previous records, the locks will eventually be released by the log flusher thread. As a result, deadlock still cannot happen in this case.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)