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

About writing a transactional state storage  #25

@jan-johansson-mr

Description

@jan-johansson-mr

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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions