[ 
https://issues.apache.org/jira/browse/IGNITE-18052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Chudov updated IGNITE-18052:
----------------------------------
    Description: 
*Motivation:*
According to the transaction protocol IEP [1] insert operation in RW 
transactions for sortex index looks as follows:

_Unique index:_
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short

_Non-unique index:_
// insert
IX_short(nextKey)
X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
IX_commit(currentKey) otherwise

This is necessary to avoid races between insert and scan operations. However, 
it's not yet implemented.

*Definition of done:*
Short term locks are acquired and released as described above.

*Implementation notes:*
For the code related to locks for indexes, see 
{{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are interested 
in {{SortedIndexLocker }}implementation, method {{locksForInsert}}. Actually, 
there is some draft, but it is commented. 

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol

  was:
*Motivation*
According to the transaction protocol IEP [1] insert operation in RW 
transactions for sortex index looks as follows:

_Unique index:_
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short

_Non-unique index:_
// insert
IX_short(nextKey)
X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
IX_commit(currentKey) otherwise

This is necessary to avoid races between insert and scan operations. However, 
it's not yet implemented.

*Definition of done:*
Short term locks are acquired and released as described above.

*Implementation notes:*
For the code related to locks for indexes, see 
{{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are interested 
in {{SortedIndexLocker }}implementation, method {{locksForInsert}}. Actually, 
there is some draft, but it is commented. 

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol


> Introduce short term locks for sorted indexes operations
> --------------------------------------------------------
>
>                 Key: IGNITE-18052
>                 URL: https://issues.apache.org/jira/browse/IGNITE-18052
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Denis Chudov
>            Priority: Major
>              Labels: ignite-3
>
> *Motivation:*
> According to the transaction protocol IEP [1] insert operation in RW 
> transactions for sortex index looks as follows:
> _Unique index:_
> // insert
> IX_short(nextKey) // released after the insertion
> X_commit(currentKey) // acquired before releasing IX_short
> _Non-unique index:_
> // insert
> IX_short(nextKey)
> X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
> IX_commit(currentKey) otherwise
> This is necessary to avoid races between insert and scan operations. However, 
> it's not yet implemented.
> *Definition of done:*
> Short term locks are acquired and released as described above.
> *Implementation notes:*
> For the code related to locks for indexes, see 
> {{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are 
> interested in {{SortedIndexLocker }}implementation, method 
> {{locksForInsert}}. Actually, there is some draft, but it is commented. 
> [1] 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to