Alexey Goncharuk updated IGNITE-7692:
    Labels: usability  (was: )

> affinityCall and affinityRun may execute code on backup partitions
> ------------------------------------------------------------------
>                 Key: IGNITE-7692
>                 URL: https://issues.apache.org/jira/browse/IGNITE-7692
>             Project: Ignite
>          Issue Type: Bug
>          Components: sql
>    Affects Versions: 2.1
>            Reporter: Alexey Goncharuk
>            Priority: Major
>              Labels: usability
>             Fix For: 2.5
> Apparently, the affinityCall and affinityRun methods reserve partitions and 
> check their state to be OWNING, however, if topology changes and partition 
> role is changed to backup from primary, the code is still executed.
> This can be an issue if a user executes a local SQL query inside the 
> affinityCall runnable. In this case, the query result may return null.
> This can be observed in the 
> IgniteCacheLockPartitionOnAffinityRunTest#getPersonsCountSingleCache - note 
> an additional check I've added to make the test pass.
> I think it is ok to have an old semantics for the API, because in some cases 
> (scan query, local gets) a backup OWNER is enough. However, it looks like we 
> need to add another API method to enforce that affinity run be executed on 
> primary nodes and forbid primary role change.
> Another option is to detect a topology version of the affinity run and use 
> that version for local SQL queries.

This message was sent by Atlassian JIRA

Reply via email to