[
https://issues.apache.org/jira/browse/IGNITE-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16666330#comment-16666330
]
Igor Seliverstov commented on IGNITE-9435:
------------------------------------------
[~Artem Budnikov], several comments from me:
There are several mistakes in implementation description:
{noformat}
When a transaction requests a specific data item to work on, it does not work
with the item directly, but obtains a version of that item (a copy of the
current value). This version is confined to the context of the transaction and
cannot be modified by other users. If another transaction accesses the same
item, it obtains yet another version and works with it. Thus, multiple versions
of the same item can coexist, by they are isolated from each other and confined
to the transactions they were generated for. Each transaction, as it were, sees
a snapshot of data at the time the transaction starts and can only modify the
data within that snapshot. The snapshot is always consistent and guaranteed not
to be modified by other transactions.{noformat}
a version of item isn't a copy of current value - it's a version of value at
the specific time.
Transactions don't copy items while requesting them - they read already existed
entries applying a special filter not to see too old or too new versions but
see the most actual (at the time the transaction have been started) ones, to do
that we use *snapshots* - a kind of point at the global timeline having an
information about finished and active transactions at this specific time.
Modifying an entry a transaction doesn't made any modifications in existed
values - it makes a new version of entry with modified fields/columns values.
That means all versions are mutable and can be easily shared between several
transactions/queries - that's why we don't need any locks to read an entry.
Before modifying a transaction has to acquire a write lock on an entry, all the
locks will be released as soon as the transaction is finished. That means what
*we allow non-blocking reads but blocking writes*.
Versions aren't put (copied) into any context, we just restrict cleaning
versions, which may be visible for any query or transaction and share them
between active transactions.
After the version become invisible (when there is a later version of entry
which is visible for any query/transaction or the version is a result of rolled
back transaction) it will be cleaned by the first writer who modified the entry
or by vacuum worker in background.
Another comment - the article has 2.6 version, isn't it a mistake? We don't
have such feature in Ignite 2.6
> Document MVCC
> -------------
>
> Key: IGNITE-9435
> URL: https://issues.apache.org/jira/browse/IGNITE-9435
> Project: Ignite
> Issue Type: Task
> Components: documentation, mvcc
> Reporter: Vladimir Ozerov
> Assignee: Igor Seliverstov
> Priority: Major
> Fix For: 2.7
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
