phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chinmay Kulkarni (Jira)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-6066) MetaDataEndpointImpl.doGetTable should acquire a readLock instead of an exclusive writeLock on the table header row
Date Mon, 10 Aug 2020 21:53:00 GMT

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

Chinmay Kulkarni updated PHOENIX-6066:
--------------------------------------
    Description: 
Throughout MetaDataEndpointImpl, wherever we need to acquire a row lock we call [MetaDataEndpointImpl.acquireLock|https://github.com/apache/phoenix/blob/bba7d59f81f2b91342fa5a7ee213170739573d6a/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2377-L2386]
which gets an exclusive writeLock on the specified row [by default|https://github.com/apache/phoenix/blob/bba7d59f81f2b91342fa5a7ee213170739573d6a/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2378].

Thus, even operations like doGetTable/getSchema/getFunctions which are not modifying the row
will acquire a writeLock on these metadata rows when a readLock should be sufficient (see
[doGetTable locking|https://github.com/apache/phoenix/blob/bba7d59f81f2b91342fa5a7ee213170739573d6a/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2932]
as an example). The problem with this is, even a simple UPSERT/DELETE or SELECT query triggers
a doGetTable (if the schema is not cached) and can potentially block other DDLs and more importantly
other queries since these queries will wait until they can get a rowLock for the table header
row. Even seemingly unrelated operations like a CREATE VIEW AS SELECT * FROM T can block a
SELECT/UPSERT/DELETE on table T since the create view code needs to fetch the schema of the
parent table.

Note that this is exacerbated in cases where we do server-server RPCs while holding rowLocks
for example ([this|https://github.com/apache/phoenix/blob/1d844950bb4ec8221873ecd2b094c20f427cd984/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2459-L2461]
and [this|https://github.com/apache/phoenix/blob/1d844950bb4ec8221873ecd2b094c20f427cd984/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2479-L2484])

This Jira is to discuss the possibility of acquiring a readLock in these "read metadata" paths
to avoid blocking other "read metadata" requests stemming from concurrent queries. The current
behavior is potentially a perf issue for clients that disable update-cache-frequency.

  was:
Throughout MetaDataEndpointImpl, wherever we need to acquire a row lock we call [MetaDataEndpointImpl.acquireLock|https://github.com/apache/phoenix/blob/bba7d59f81f2b91342fa5a7ee213170739573d6a/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2377-L2386]
which gets an exclusive writeLock on the specified row [by default|https://github.com/apache/phoenix/blob/bba7d59f81f2b91342fa5a7ee213170739573d6a/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2378].


Thus, even operations like doGetTable/getSchema/getFunctions which are not modifying the row
will acquire a writeLock on these metadata rows when a readLock should be sufficient (see
[doGetTable locking|https://github.com/apache/phoenix/blob/bba7d59f81f2b91342fa5a7ee213170739573d6a/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2932]
as an example). The problem with this is, even a simple UPSERT/DELETE or SELECT query triggers
a doGetTable (if the schema is not cached) and can potentially block other DDLs and more importantly
other queries since these queries will wait until they can get a rowLock for the table header
row. Even seemingly unrelated operations like a CREATE VIEW AS SELECT * FROM T can block a
SELECT/UPSERT/DELETE on table T since the create view code needs to fetch the schema of the
parent table.

This Jira is to discuss the possibility of acquiring a readLock in these "read metadata" paths
to avoid blocking other "read metadata" requests stemming from concurrent queries. The current
behavior is potentially a perf issue for clients that disable update-cache-frequency.


> MetaDataEndpointImpl.doGetTable should acquire a readLock instead of an exclusive writeLock
on the table header row
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-6066
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-6066
>             Project: Phoenix
>          Issue Type: Improvement
>    Affects Versions: 5.0.0, 4.15.0
>            Reporter: Chinmay Kulkarni
>            Priority: Major
>              Labels: quality-improvement
>             Fix For: 5.1.0, 4.16.0
>
>
> Throughout MetaDataEndpointImpl, wherever we need to acquire a row lock we call [MetaDataEndpointImpl.acquireLock|https://github.com/apache/phoenix/blob/bba7d59f81f2b91342fa5a7ee213170739573d6a/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2377-L2386]
which gets an exclusive writeLock on the specified row [by default|https://github.com/apache/phoenix/blob/bba7d59f81f2b91342fa5a7ee213170739573d6a/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2378].
> Thus, even operations like doGetTable/getSchema/getFunctions which are not modifying
the row will acquire a writeLock on these metadata rows when a readLock should be sufficient
(see [doGetTable locking|https://github.com/apache/phoenix/blob/bba7d59f81f2b91342fa5a7ee213170739573d6a/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2932]
as an example). The problem with this is, even a simple UPSERT/DELETE or SELECT query triggers
a doGetTable (if the schema is not cached) and can potentially block other DDLs and more importantly
other queries since these queries will wait until they can get a rowLock for the table header
row. Even seemingly unrelated operations like a CREATE VIEW AS SELECT * FROM T can block a
SELECT/UPSERT/DELETE on table T since the create view code needs to fetch the schema of the
parent table.
> Note that this is exacerbated in cases where we do server-server RPCs while holding rowLocks
for example ([this|https://github.com/apache/phoenix/blob/1d844950bb4ec8221873ecd2b094c20f427cd984/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2459-L2461]
and [this|https://github.com/apache/phoenix/blob/1d844950bb4ec8221873ecd2b094c20f427cd984/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2479-L2484])
> This Jira is to discuss the possibility of acquiring a readLock in these "read metadata"
paths to avoid blocking other "read metadata" requests stemming from concurrent queries. The
current behavior is potentially a perf issue for clients that disable update-cache-frequency.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message