Vladislav Pyatkov created IGNITE-28724:
------------------------------------------
Summary: Calcite engine. Support for 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
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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
