Events saved to eventstore based on transaction system

[codemasternode]

What is this feature about?

This feature is about saving events to eventstore with possiblity to rolling back those events if something fails.
I have such situation:

1. I'm publishing events to eventstore
2. I need to make ajax call to other microservice/3-rd party resource to make some action
3. This microservice/3-rd party resource fail with 400
4. I need to rollback events that was saved in eventstore and reject whole command action

Currently i'm not be able to do that because wolkenkit-eventstore doesn't support transactions.

What needs to be done to implement this feature?

• I need a seperate method to start transaction and save events, which return some object with methods named for example rollback and commit to be able to reject/finish transaction

[goloroden]

Hey @codemasternode 👋

Thanks for bringing up this issue. Am I getting this correctly that you do not use wolkenkit as a framework, just the eventstore as a standalone package?

[codemasternode]

@goloroden yep

[goloroden]

@codemasternode Okay … in wolkenkit we solve this as follows: When the command handler publishes events, we do not directly store them to the event store, but first of all collect them in-memory. Then, once the command handler succeeds, we store them in an all-or-nothing approach in the event store.

So, if an error happens somewhere before, we do not even get to the point where we might need to rollback.

Would this be a viable alternative to you?

[codemasternode]

Ok, maybe i'm looking in bad place, but what if you put this in memory, ajax calls to 3-rd party succedd, but saving to eventstore fail because application lost connection with database for a while ? It's possible case scenario.

[goloroden]

This is true – but you always have this problem, even if the event store had support for rollbacks:

What if you start a transaction, store events, make your AJAX calls, and then, just the millisecond before you commit, your process crashes? The transaction will the be rolled back automatically by the database, because your process is gone, and are left with the same situation as before.

Long story short: In a distributed system you never have "exactly once" semantics, you only can decide whether – in case you detect an error – you are going to do things twice if in doubt, or if you prefer to risk not having it done at all. This is the decision between "at least once" and "at most once" semantics.

The answer to this depends on the specific use case, so there is no general "right" or "wrong" way to do it.

[codemasternode]

Ok thx, so i was looking for solution in a bad direction.

[goloroden]

No problem, you're welcome 😊

[codemasternode]

@goloroden ok, i found one case, what if i have two eventstores (two different tables) i would like to save, that are in the same database. And one action succedd and one fail, this can be potential use case for transaction.

[goloroden]

Technically speaking, yes, this would be a use case where you'd actually need to be able to access the underlying transaction. However, spanning an event store across multiple tables is not supported right now, and I think I'd probably solve it in a different way (by being able to define which events to store where, and then let the event store do the magic itself).

However: Is this an actual use case, or more a theoretical use case?

[codemasternode]

No, it's only theoretical.