Description
We need to store lock info inside tuples. Otherwise, touching a lot of entries would lead to OOME. Also we should rework our locking logic - instead of trying to enlist ourselves in every entry, we should stop on the very first locked entry and wait for it's release.
Suggested fix:
1) Check for lock_id field of an entry
2) If it is empty, CAS own XID
3) If it is not empty, check fo TX LOG to see if transaction is still active; if not - CAS itself
4) If failed to install own version - stop locking and wait for release
5) When transaction commits, no locks are released explicilty. Instead, it is responsibility of the next locker to check TX LOG and undesrantnad whether entry could be locked or not
6) When lock is acquired, create new version of an entry with lock info
Attachments
Issue Links
- Is contained by
-
IGNITE-4191 SQL: support transactions
-
- Resolved
-