[jira] [Closed] (ASTERIXDB-1504) Locking during upsert operation may cause deadlock when the job plan of the upsert AQL has a blocking operator during search phase.

["Young-Seok Kim (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ASTERIXDB-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Young-Seok Kim closed ASTERIXDB-1504.
-------------------------------------
    Resolution: Invalid

This issue was created with incorrect understanding of the upsert operation. Currently, upsert operation acquires exclusive locks after records to be upserted are searched. So, there is no blocking operator issue during acquiring the exclusive locks.

> Locking during upsert operation may cause deadlock when the job plan of the upsert AQL has a blocking operator during search phase.
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERIXDB-1504
>                 URL: https://issues.apache.org/jira/browse/ASTERIXDB-1504
>             Project: Apache AsterixDB
>          Issue Type: Bug
>            Reporter: Young-Seok Kim
>
> The current upsert operation does not work correctly based on the deadlock-free locking protocol when the query in the upsert statement has any blocking operator in the job pipeline.
> According to the deadlock-free locking protocol, when a trylock() fails for a record to be upserted during search phase from the query clause, all records that already acquired lock should be pushed to the commit operator before a lock()(blocking call) is called for the trylock-failed record  in order to avoid the hold-and-wait situation.
> However, when there is any blocking operator in the pipeline, the pushed operator may not reach the commit operator. So, upsert with a blocking operator breaks the deadlock-free locking protocol.
> This should be fixed. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)