[
https://issues.apache.org/jira/browse/IGNITE-28724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-28724:
---------------------------------------
Description:
h3. Motivation
The Calcite SQL engine currently lacks support for the standard SELECT ... FOR
UPDATE syntax. This syntax is widely used across industry-standard databases to
explicitly acquire exclusive locks on records during the read phase of a
transaction.
{code:sql}
SELECT ... FROM ... WHERE ... FOR UPDATE [WAIT <N> | NOWAIT]
{code}
h3. Implementation Notes
This is an umbrella ticket designed to track the parsing, validation, and
execution roadmap. The feature will rely on the existing key-based locking
protocol.
h4. Core Logic Flow:
# Scan & Track: Perform a distributed scan matching the WHERE clause,
capturing primary keys and their current data versions.
# Lock Acquisition: Attempt to acquire exclusive locks on the filtered keys.
# Version Conflict Handling: If a concurrent transaction modifies the records
between the scan and lock phases, the execution layer must release any acquired
locks, clear the state, and trigger an internal retry.
For details, you can look at [the Apache Ignite dev
list|https://lists.apache.org/thread/g8rszqmw5dqgsg055w6by0v2dnjc9hwy].
h3. Definition of Done
* SQL Parser successfully recognizes FOR UPDATE clauses alongside WAIT,
NOWAIT, and SKIP LOCKED options.
* The validation layer correctly isolates and blocks forbidden clauses (JOIN,
GROUP BY, etc.) with user-friendly errors.
* Exclusive locks are successfully acquired during execution and reliably held
until transaction boundaries.
was:
h3. Motivation
The Calcite SQL engine currently lacks support for the standard SELECT ... FOR
UPDATE syntax. This syntax is widely used across industry-standard databases to
explicitly acquire exclusive locks on records during the read phase of a
transaction.
{code:sql}
SELECT ... FROM ... WHERE ... FOR UPDATE [WAIT <N> | NOWAIT | SKIP LOCKED]
{code}
h3. Implementation Notes
This is an umbrella ticket designed to track the parsing, validation, and
execution roadmap. The feature will rely on the existing key-based locking
protocol.
h4. Core Logic Flow:
# Scan & Track: Perform a distributed scan matching the WHERE clause,
capturing primary keys and their current data versions.
# Lock Acquisition: Attempt to acquire exclusive locks on the filtered keys.
# Version Conflict Handling: If a concurrent transaction modifies the records
between the scan and lock phases, the execution layer must release any acquired
locks, clear the state, and trigger an internal retry.
For details, you can look at [the Apache Ignite dev
list|https://lists.apache.org/thread/g8rszqmw5dqgsg055w6by0v2dnjc9hwy].
h3. Definition of Done
* SQL Parser successfully recognizes FOR UPDATE clauses alongside WAIT,
NOWAIT, and SKIP LOCKED options.
* The validation layer correctly isolates and blocks forbidden clauses (JOIN,
GROUP BY, etc.) with user-friendly errors.
* Exclusive locks are successfully acquired during execution and reliably held
until transaction boundaries.
> Calcite engine. Support SELECT ... FOR UPDATE query
> ---------------------------------------------------
>
> Key: IGNITE-28724
> URL: https://issues.apache.org/jira/browse/IGNITE-28724
> Project: Ignite
> Issue Type: Improvement
> Reporter: Vladislav Pyatkov
> Assignee: Vladislav Pyatkov
> Priority: Major
> Labels: ignite-2
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Motivation
> The Calcite SQL engine currently lacks support for the standard SELECT ...
> FOR UPDATE syntax. This syntax is widely used across industry-standard
> databases to explicitly acquire exclusive locks on records during the read
> phase of a transaction.
> {code:sql}
> SELECT ... FROM ... WHERE ... FOR UPDATE [WAIT <N> | NOWAIT]
> {code}
> h3. Implementation Notes
> This is an umbrella ticket designed to track the parsing, validation, and
> execution roadmap. The feature will rely on the existing key-based locking
> protocol.
> h4. Core Logic Flow:
> # Scan & Track: Perform a distributed scan matching the WHERE clause,
> capturing primary keys and their current data versions.
> # Lock Acquisition: Attempt to acquire exclusive locks on the filtered keys.
> # Version Conflict Handling: If a concurrent transaction modifies the
> records between the scan and lock phases, the execution layer must release
> any acquired locks, clear the state, and trigger an internal retry.
> For details, you can look at [the Apache Ignite dev
> list|https://lists.apache.org/thread/g8rszqmw5dqgsg055w6by0v2dnjc9hwy].
> h3. Definition of Done
> * SQL Parser successfully recognizes FOR UPDATE clauses alongside WAIT,
> NOWAIT, and SKIP LOCKED options.
> * The validation layer correctly isolates and blocks forbidden clauses
> (JOIN, GROUP BY, etc.) with user-friendly errors.
> * Exclusive locks are successfully acquired during execution and reliably
> held until transaction boundaries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
