Fix deadlock failure when listing objects in SQL Server connector #27259
Conversation
ebyhr
force-pushed
the
ebi/sqlserver-list-failure
branch
from
f2ed50d to
207e1f9
Compare
| throws SQLException | ||
| { | ||
| Connection connection = connectionFactory.openConnection(session); | ||
| connection.setTransactionIsolation(TRANSACTION_READ_UNCOMMITTED); |
There was a problem hiding this comment.
What is the downside of using TRANSACTION_READ_UNCOMMITTED for table listing?
There was a problem hiding this comment.
The downside is potential risk of dirty reads. For instance, the connector might see a table that will be rolled back (doesn't really exist).
There was a problem hiding this comment.
I don't think "read uncommitted" is desired.
the sql server's snapshot isolation was supposed to avoid deadlocks.
Besides, listing operations should be retried on retryable exceptions (as should be all other forms of network communication with external services), and those retries would likely solve the problem at hand
plugin/trino-sqlserver/src/test/java/io/trino/plugin/sqlserver/TestSqlServerConnectorTest.java
Show resolved
Hide resolved
It would be worthwhile to explain what is the rationale for going with the TRANSACTION_READ_UNCOMMITTED isolation level. |
| { | ||
| super.testShowTablesLike(); | ||
| try { | ||
| super.testUpdateRowConcurrently(); |
There was a problem hiding this comment.
This test creates test_update_row... tables which will likely left unaffected the SHOW TABLES LIKE 'or%' query from testShowTablesLike.
There was a problem hiding this comment.
That is fine because the condition isn't pushed-down to SQL Server. I confirmed the current test can reproduce a deadlock issue.
This resolve "Transaction was deadlocked on lock resources with another process" when listing objects in SQL Server connector.
ebyhr
force-pushed
the
ebi/sqlserver-list-failure
branch
from
207e1f9 to
17700c0
Compare
|
CI hit #26567 |
3 participants
Description
Fixes #10846
Another approach would be adding retry logic.
Release notes