You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 21, 2022. It is now read-only.
I'd be happy to write a transactional state storage, however, the documentation about how to go about it is missing in the documentation. The documentation states that ITransactionalStateStorage is the abstraction of a transactional store.
When creating a class implementing the defined interface we have
public class State
{
}
public class TransactionalStore : ITransactionalStateStorage<State>
{
public Task<TransactionalStorageLoadResponse<State>> Load()
{
throw new NotImplementedException();
}
public Task<string> Store(
string expectedETag
, TransactionalStateMetaData metadata
, List<PendingTransactionState<State>> statesToPrepare
, long? commitUpTo, long? abortAfter)
{
throw new NotImplementedException();
}
}
That's great, but what is TransactionalStorageLoadResponse, and what am I supposed to do with TransactionalStateMetaData and what does List<PendingTransactionState<State>> statesToPrepare bring to the table? And so on.
I guess I can start out by studying AzureTableTransactionalStateStorage to see how it is implemented. Do you guys have any plans on further expand on the transactional implementation details in the documentation to ease the task of writing a transactional storage provider?
There is one passage in the documentation that's a little concerning
For development purposes, if transaction-specific storage is not available for the data store you
need, an `IGrainStorage` implementation may be used instead. For any transactional state that does
not have a store configured for it, transactions will attempt to fail over to grain storage using a bridge.
Accessing transactional state via a bridge to grain storage will be less efficient and is not a pattern we
intend to support long term, hence the recommendation that this only be used for development purposes.
What I understand from this passage is that since the only storage provider that exists today is with Azure, that either another transactional storage provider (e.g. Ado) has to be written (hence my interest in how to write such a storage provider), or once the bridging is not supported anymore that unless I connect to Azure then transactional pattern is not supported by Orleans.
Thanks for an amazing framework!
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi @ReubenBond, @jason-bragg,
I'd be happy to write a transactional state storage, however, the documentation about how to go about it is missing in the documentation. The documentation states that
ITransactionalStateStorage
is the abstraction of a transactional store.When creating a class implementing the defined interface we have
That's great, but what is
TransactionalStorageLoadResponse
, and what am I supposed to do withTransactionalStateMetaData
and what doesList<PendingTransactionState<State>> statesToPrepare
bring to the table? And so on.I guess I can start out by studying
AzureTableTransactionalStateStorage
to see how it is implemented. Do you guys have any plans on further expand on the transactional implementation details in the documentation to ease the task of writing a transactional storage provider?There is one passage in the documentation that's a little concerning
What I understand from this passage is that since the only storage provider that exists today is with Azure, that either another transactional storage provider (e.g. Ado) has to be written (hence my interest in how to write such a storage provider), or once the bridging is not supported anymore that unless I connect to Azure then transactional pattern is not supported by Orleans.
Thanks for an amazing framework!
The text was updated successfully, but these errors were encountered: