[
https://issues.apache.org/jira/browse/PHOENIX-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17175134#comment-17175134
]
Lars Hofhansl commented on PHOENIX-6066:
----------------------------------------
Good find. Logically it should not be needed. (I do not think we do any writes
when we read back the metadata.)
In practice we'd need to study/try this carefully (for a example the way it is
implemented, HBase will always return a new exclusive lock, but will return an
existing read-lock when the same thread requests read-lock on the same row
again).
I'm all for changing it.
Did you observe this as an actual performance problem, or is this more
hypothetical?
> 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)
