[
https://issues.apache.org/jira/browse/PHOENIX-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17175146#comment-17175146
]
Chinmay Kulkarni commented on PHOENIX-6066:
-------------------------------------------
[~larsh] Thanks. Yes, agreed that we need to study this thoroughly.
I observed this while doing some contrived testing where I concurrently create
views while querying the base table (no specific perf test as such). I saw that
when we try to acquire a read-lock for the same row key, HBase will immediately
return the same existing read-lock, even if the requesting thread is different.
We do however increment the count of read-lock requests in the
HRegion.RowLockContext. I'm not sure about the details of RowLockContext, so
will need to look into it to know if this is okay or not. Please let me know if
you have any pointers around this.
Since we don't really have too many tests that do DDL, DML/DQL concurrently, it
might not be easy to find a regression by just putting up a patch for Hadoop
QA. I will read up more about this and think about some test cases.
> 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])
> which is another issue altogether.
> 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)
