[
https://issues.apache.org/jira/browse/ASTERIXDB-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16376316#comment-16376316
]
ASF subversion and git services commented on ASTERIXDB-2299:
------------------------------------------------------------
Commit 7ec813cc57a34b0e190e0cb22ef2a0e99541e9d8 in asterixdb's branch
refs/heads/master from [~luochen01]
[ https://git-wip-us.apache.org/repos/asf?p=asterixdb.git;h=7ec813c ]
[ASTERIXDB-2299] Set log type properly during modifications
- user model changes: no
- storage format changes: no
- interface changes: no
Details:
- Previously we have a deadlock-free protocol during normal ingestion
pipeline. When the try lock fails, we flush the frame partially so that
they can release locks, and log a WAIT record to wake up after that.
However, after logging the WAIT record, we didn't set the log type
back to UPDATE. This seriously degrades the ingestion performance
afterwords since all updates log records would become WAIT log records,
which require heavier logic to process upon the log is flushed to
disk.
Change-Id: Ibcf93072ca0833cb24ba6719796f58df56384c3b
Reviewed-on: https://asterix-gerrit.ics.uci.edu/2424
Sonar-Qube: Jenkins <[email protected]>
Tested-by: Jenkins <[email protected]>
Contrib: Jenkins <[email protected]>
Reviewed-by: Murtadha Hubail <[email protected]>
> Update LogRecord type is not correctly set after logging the WAIT record
> ------------------------------------------------------------------------
>
> Key: ASTERIXDB-2299
> URL: https://issues.apache.org/jira/browse/ASTERIXDB-2299
> Project: Apache AsterixDB
> Issue Type: Bug
> Components: TX - Transactions
> Reporter: Chen Luo
> Assignee: Chen Luo
> Priority: Critical
>
> We have a deadlock free locking protocol to avoid introducing deadlocks
> during ingestions.
> [https://cwiki.apache.org/confluence/display/ASTERIXDB/Deadlock-Free+Locking+Protocol.]
> However, after logging the WAIT record, it didn't set the log type back to
> UPDATE for normal updates.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
