With #3186, we are introducing concurrent modifications to the PartitionStore while an invoker might read data from it (e.g. when retrying). Before, there was a delicate protocol in place which prevented reading from the PartitionStore while a pending write (e.g. journal entry append) was in flight. However, with trimming of the journals which might happen at any point in time, this is no longer true. As a consequence, the JournalReader implementation InvokerStorageReader which reads the JournalMetadata and the Journal might see both values at different point in times (read skew). Concretely what could happen is that the InvokerStorageReader reads the JournalMetadata before the journal was trimmed, then the journal is being trimmed and then it reads the trimmed Journal which no longer corresponds to the read JournalMetadata.
To solve this problem, one solution could be to use snapshot isolation for reads to prevent any kind of read skew happening.
With #3186, we are introducing concurrent modifications to the
PartitionStorewhile an invoker might read data from it (e.g. when retrying). Before, there was a delicate protocol in place which prevented reading from thePartitionStorewhile a pending write (e.g. journal entry append) was in flight. However, with trimming of the journals which might happen at any point in time, this is no longer true. As a consequence, theJournalReaderimplementationInvokerStorageReaderwhich reads theJournalMetadataand theJournalmight see both values at different point in times (read skew). Concretely what could happen is that theInvokerStorageReaderreads theJournalMetadatabefore the journal was trimmed, then the journal is being trimmed and then it reads the trimmedJournalwhich no longer corresponds to the readJournalMetadata.To solve this problem, one solution could be to use snapshot isolation for reads to prevent any kind of read skew happening.