|
||||||||
|
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 |
||||||||
|
||||||||
|
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 |
||||||||
I think the best bet here is going to be a special recognition of cases where a query attempts to both:
and in such cases, for Dialects which do not support that (ok, for Oracle), continue applying the paging in the SQL and then apply the locking in a follow-up. We should also be able to identify cases where the follow-up locking would not be possible (scalar selects, etc) and skip the follow-up locking and issue a warning.
The reason I think this is the best option is that it is the most applicable. Yes it does allow a slight possibility that a row might be updated or locked between the initial select (paging) and the subsequent lock attempt.
Note that to a degree native-sql queries are a little outside this above discussion since we really do not know the semantics of the query.
As stated above,