Orleans storage provider for Orleans

EventStoreDB
1

Hi,

Just published a storage provider for MS Orleans: https://github.com/jkonecki/Orleans.EventSourcing.

The implementation may be a bit naive but may be helpful if you want to quickly spike migration of your existing EventStore application to Orleans.

Feedback welcomed!

Jakub

2

Do you think a transaction is actually needed here? It is much more expensive to write that way that to use atomic writes.

3

Just out of curiousity: From what I understand a transaction in Orleans can span multiple actors/grains. Is this handled somehow in this implementation, or is it more a matter of crossing your fingers and hoping for the best? :wink:

/Peter

4

As of now transactions are limited to a single stream (as they should be) writing transactionally through multiple actors is considered an anti-pattern

5

“That said, support for cross-actor transactions is a topic under investigation.” from http://blogs.msdn.com/b/dotnet/archive/2014/04/02/available-now-preview-of-project-orleans-cloud-services-at-scale.aspx

6

Seems like they’re not quite clear on the behaviour:

“By default, all of the grains that process an external
request are included within a single transaction, so that the request
executes atomically and in isolation”

(http://research.microsoft.com/pubs/153347/socc125-print.pdf))

Doesn’t matter, I personally think it looks like a mess (code-gen etc), and stopped investigating further after the above whitepaper…

/Peter

7

There is a fix for this “mess” in a progress … :wink:

8

That should be a “no-go”. It just breaks the whole idea of
autonomous agents

9

That paper suggests (emphasis mine):

  1. Orleans transactions are atomic, consistent, isolated, and durable. During execution, a transaction sees only a single activation of each grain involved in the transaction, thus every transaction
    by itself sees a consistent application state. This state is isolated from changes made by concurrently executing transactions.
    A transaction’s
    updates to durable storage, even if they occur in multiple grains, become visible atomically to subsequent transactions when the transaction completes; so another transaction sees the
    entire, consistent set of changes from a completed transaction. **Updates across many grains are atomically committed to durable storage, providing a consistent mechanism for persisting the result of a computation. **

Seems to be some conflicting information around

10

yes.

There are however some libraries for instance in erlang to handle this (paxos)

11

yeah I would not make this a requirement.

When using a transaction now in event store btw it is scoped to a stream onbly!

We could make this more relaxed inside a single replica set.

12

Current Storage Provider API has no notion of the transaction.

As others stated before cross-actor transactions are not the best ideas, especially since the actors may be running in separate silos (physical nodes) and we’re back to DTC world of pain and misery.

Jakub

13

Greg,

So should i just get rid of the transaction and call AppendToStreamAsync passing all the events?

Jakub

14

Generally that would be prefered for up to a significantly large number of events (say a few hundred)

Maybe offer a way to say I need to stream them instead like what you do now.

Greg

15

I wouldn’t dismiss it that quickly.
I have a feeling after talking to some guys during London Azure User group that you may see Orleans tab in Azure portal one day…

Jakub

16

My guess is you will. Its a much better model for services in the cloud.

17

Current write page size is 500 so for smaller number of events there will be no transaction.

What do you mean by ‘stream them instead’?

Jakub

18

Yes, I’m fully aware of the target platform, and I’m very intrested in actor model. I just don’t like the approach they’ve taken, excplicit message passing usually turns out a lot cleaner than trying to mimic local method calls across the network, in my experience… But I guess you could program in that style yourself, on top of the framework.

/Peter

19

Yes, you can do it on top of it. But it’s quite involved :slight_smile:

In fact, nothing stopping you to have actor methods which simply

accept a single message parameter.
Even polymorphic dispatch works out of the box. So you can have a
higher-order function which accepts some base Message interface.
And then dispatch internally (inside actor) to a more specific
handler by using “dynamic”.

But you'll still need to obtain a reference to an actor by using

some obnoxious static factory, codegened by Orleans MSBuild target.
That’s really ugly and not unit-test friendly, at all.

To overcome this, framework need to do some form of DI.
I hope they fix this in the next release, given we have provided a

lot of feedback on this.

I did some work on message bus for Orleans, and it's started

breezing but still in flux.
I hope to combine Orleans.Bus with Orleans.EventSourcing to have
Orleans.CQRS soon :slight_smile:

20

Orleans.EventSourcing will be even more compelling with sharding.

I think there can be some specific stuff done with Orleans to make it better by getting close to orleans from a ges perspective similar to akka stuff in the jvm api