Transactions and AzureTableTransactionalStateStorage #7008
Unanswered
BrianSakhai
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
I am writing a custom storage class based on AzureTableTransactionalStateStorage (https://github.com/dotnet/orleans/blob/master/src/Azure/Orleans.Transactions.AzureStorage/TransactionalState/AzureTableTransactionalStateStorage.cs). I noticed that calls to grains that only read the state through PerformRead still call the Store method and result in a call to Azure Storage (or in my case to Cosmos), updating the Metadata property on the KeyEntity (nothing else). Is this the intended behavior?
For example, in case my question is not clear, I am seeing this flow:
Call to CustomerGrain.GetCustomerName() ->
Grain method calls PerformRead ->
StorageClass calls Load and reads KeyEntity and States from Azure Storage ->
StorageClass calls Store and writes KeyEntity (same version, new metadata) to Azure Storage.
Is that call to Store intentional and needed? My guess is that it is, in order to prevent reading an outdated state in the event the state is changed mid transaction (for example if there are multiple activations).
Also, as a side note, my reading of the code is that ReadStates is relying on Azure Storage returning the states in the correct order.
orleans/src/Azure/Orleans.Transactions.AzureStorage/TransactionalState/AzureTableTransactionalStateStorage.cs
Line 130 in 0198923
Is my interpretation correct? If so, Cosmos Db does not guarantee ordering on RowKey. So the ReadStates function would need to sort results before returning if using Cosmos Db's Table API.
Thank you.
Beta Was this translation helpful? Give feedback.
All reactions