[jira] [Updated] (IGNITE-18219) Actual token is compared twice in VersionedValue#getInternal

["Denis Chudov (Jira)" <ji...@apache.org>]

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

Denis Chudov updated IGNITE-18219:
----------------------------------
    Description: 
*Motivation:*

Following code may be erroneous:
{code:java}
        if (causalityToken <= actualToken0) {
            return getValueForPreviousToken(causalityToken);
        }

        trimHistoryLock.readLock().lock();

        try {
            if (causalityToken <= actualToken0) {
                return getValueForPreviousToken(causalityToken);
            }
{code}

The original intention of making {{trimHistoryLock}} in {{VersionedValue}} class was to make adding tokens to {{history}} and switching actual token atomic. Seems that this atomicity has been lost after some changes. Need to dive deeper into it and fix possible problems related to consistency of internal mutable state of VersionedValue, and necessity of trimHistoryLock in presence of updateMutex.

*Definition of done:*
There should be either one mutex left or necessity of both of them explained in javadoc. Possibly, it is worth making multithreaded test for VersionedValue which would change the history concurrently with high intensity.

  was:
*Motivation:*

Following code may be erroneous:
{code:java}
        if (causalityToken <= actualToken0) {
            return getValueForPreviousToken(causalityToken);
        }

        trimHistoryLock.readLock().lock();

        try {
            if (causalityToken <= actualToken0) {
                return getValueForPreviousToken(causalityToken);
            }
{code}

The original intention of making {{trimHistoryLock}} in {{VersionedValue}} class was to make adding tokens to history and switching actual token atomic. Seems that this atomicity has been lost after some changes. Need to dive deeper into it and fix possible problems related to consistency of internal mutable state of VersionedValue, and necessity of trimHistoryLock in presence of updateMutex.

*Definition of done:*
There should be either one mutex left or necessity of both of them explained in javadoc. Possibly, it is worth making multithreaded test for VersionedValue which would change the history concurrently with high intensity.


> Actual token is compared twice in VersionedValue#getInternal
> ------------------------------------------------------------
>
>                 Key: IGNITE-18219
>                 URL: https://issues.apache.org/jira/browse/IGNITE-18219
>             Project: Ignite
>          Issue Type: Bug
>            Reporter: Denis Chudov
>            Priority: Major
>              Labels: ignite-3
>
> *Motivation:*
> Following code may be erroneous:
> {code:java}
>         if (causalityToken <= actualToken0) {
>             return getValueForPreviousToken(causalityToken);
>         }
>         trimHistoryLock.readLock().lock();
>         try {
>             if (causalityToken <= actualToken0) {
>                 return getValueForPreviousToken(causalityToken);
>             }
> {code}
> The original intention of making {{trimHistoryLock}} in {{VersionedValue}} class was to make adding tokens to {{history}} and switching actual token atomic. Seems that this atomicity has been lost after some changes. Need to dive deeper into it and fix possible problems related to consistency of internal mutable state of VersionedValue, and necessity of trimHistoryLock in presence of updateMutex.
> *Definition of done:*
> There should be either one mutex left or necessity of both of them explained in javadoc. Possibly, it is worth making multithreaded test for VersionedValue which would change the history concurrently with high intensity.



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