Skip to content
This repository was archived by the owner on Mar 21, 2022. It is now read-only.

About writing a transactional state storage #25

Open
jan-johansson-mr opened this issue Apr 2, 2021 · 0 comments
Open

About writing a transactional state storage #25

jan-johansson-mr opened this issue Apr 2, 2021 · 0 comments

Comments

@jan-johansson-mr
Copy link

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

    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!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant