db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "H Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6300) row locks incorrectly taken for rows that do not match SELECT predicate
Date Thu, 25 Jul 2013 06:27:50 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13719290#comment-13719290

H Zhang commented on DERBY-6300:

Our app has fairly generic logic generating SQL queries like those in the test case for quite
a number of DB tables, so it may be tricky to tailor the SQL for this edge case. I'll look
into what we could do.

Our code has used the same isolation level for some years, so I think changing the isolation
level for this case is not much of an option for us right now.

The large IN list was intended to reduce the number of DB roundtrips, and we generally expect
large tables. It's a bit difficult for us to account for the edge case where the table is
actually small.

In an earlier comment, you mentioned: "Since you are using a prepared statement, derby chooses
a query plan without knowing what the values for the ? operators are." Would that mean that
if we didn't use a PreparedStatement, the optimizer might pick some other plan? That wasn't
clear from reading the tuning doc. I guess I should find some time and just try seeing what
Derby does in practice...

I'm fine with characterizing this issue as not a bug based on your Derby explanations above.
Ultimately, though, we'd need to follow the enhancement DERBY-6301 then, as our app hits concurrent
user issues with the locks on the unqualified rows. On other RDBMSes, we've haven't seen this
row locking issue -- so it'd be nice to see consistent locking across all the DBs we run.
> row locks incorrectly taken for rows that do not match SELECT predicate
> -----------------------------------------------------------------------
>                 Key: DERBY-6300
>                 URL: https://issues.apache.org/jira/browse/DERBY-6300
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions:,
>         Environment: Windows, Linux
>            Reporter: H Zhang
>         Attachments: derby.log, RowLocksIssue.java
> Derby seems to be taking S-locks on all the rows in a table after a SELECT query, even
when none of the rows match the query predicate. For example, after running a query like
> 	SELECT col1, col2 FROM table1 WHERE col1 IN (?, ?, ?...) WITH RS
> and the query returns 0 rows, we still see S-locks being taken on all rows in the table.
> This issue seems to be dependent on which exact query plan gets chosen to be executed,
as changing some combination of the following factors seems to avoid the issue:
> 1) The number of total rows in the table is small. In the test case, we're using 10 rows.
> 2) There is an explicitly created composite index on the table that covers all the rows.
> 3) The number of values in the IN clause of the SELECT query is sufficiently large.
> What plan the optimizer chooses seems to be a factor. For example, in our actual database,
we've found we need about 5 or 6 parameters in the IN clause to reproduce the issue. In the
attached test case, it seems the issue can be seen with 3 or more parameters.
> The attached test results in a database deadlock if the row locking issue occurs. It
basically does the following:
> a) Have a table with 10 rows. The values are basically A0, A1, ...
> b) Have a transaction selecting for values C0, C1, ...
> c) Have a 2nd transaction selecting for values D0, D1, ...
> d) Execute SQL deletes from both transactions
> The test fails in (d) with a deadlock because after (b) and (c), both transactions have
S-locks on all the rows in the table.
> We've tested on 10.8.3 and, and both seem to exhibit the issue.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message