Chinmay Kulkarni created PHOENIX-6066:
-----------------------------------------

             Summary: 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: 4.15.0, 5.0.0
            Reporter: Chinmay Kulkarni
             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.

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)

Reply via email to