[jira] [Updated] (PHOENIX-6066) MetaDataEndpointImpl.doGetTable should acquire a readLock instead of an exclusive writeLock on the table header row
[ https://issues.apache.org/jira/browse/PHOENIX-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated PHOENIX-6066: Fix Version/s: 5.2.1 5.3.0 > 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 >Assignee: Palash Chauhan >Priority: Major > Labels: quality-improvement > Fix For: 5.2.1, 5.3.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.20.10#820010)
[jira] [Updated] (PHOENIX-6066) MetaDataEndpointImpl.doGetTable should acquire a readLock instead of an exclusive writeLock on the table header row
[ https://issues.apache.org/jira/browse/PHOENIX-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated PHOENIX-6066: Fix Version/s: (was: 4.17.0) (was: 4.16.2) > 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 >Assignee: Lokesh Khurana >Priority: Major > Labels: quality-improvement > > 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.20.10#820010)
[jira] [Updated] (PHOENIX-6066) MetaDataEndpointImpl.doGetTable should acquire a readLock instead of an exclusive writeLock on the table header row
[ https://issues.apache.org/jira/browse/PHOENIX-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viraj Jasani updated PHOENIX-6066: -- Fix Version/s: (was: 4.16.1) 4.16.2 > 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: 4.17.0, 4.16.2 > > > 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)
[jira] [Updated] (PHOENIX-6066) MetaDataEndpointImpl.doGetTable should acquire a readLock instead of an exclusive writeLock on the table header row
[ https://issues.apache.org/jira/browse/PHOENIX-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xinyi Yan updated PHOENIX-6066: --- Fix Version/s: (was: 4.16.0) 4.17.0 4.16.1 > 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.1, 4.17.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)
[jira] [Updated] (PHOENIX-6066) MetaDataEndpointImpl.doGetTable should acquire a readLock instead of an exclusive writeLock on the table header row
[ 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]) 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. 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. 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. > 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 >
[jira] [Updated] (PHOENIX-6066) MetaDataEndpointImpl.doGetTable should acquire a readLock instead of an exclusive writeLock on the table header row
[ 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] >
[jira] [Updated] (PHOENIX-6066) MetaDataEndpointImpl.doGetTable should acquire a readLock instead of an exclusive writeLock on the table header row
[ https://issues.apache.org/jira/browse/PHOENIX-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-6066: -- Labels: quality-improvement (was: ) > 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. > 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)
