Marten: Details around ACID

[ppumkin]

Hi
Saw your talk on NET CONF 18 and was pulled into the idea of ACID on EventStore

As I recently started using the CQRS/ES pattern and accepted the fact of eventual consistency I would like to understand how marten implements ACID?

I understand what ACID means but what I am struggling to figure out are what compromises have you made, or what are the side effects?

For example, In some production environments we rehydrate aggregates that take more than 1 second (100k+ events) before we can pass the requirements and then commit the event and having a persistent subscriber app update the read model.. the eventual consistency pattern that marten does not suffer from. The eventual consistency takes no more than 2 seconds which is acceptable for us.

So could you please explain what the technical implications are based on my example.

How do you guarantee the read store is updated, say we have a TCP/IP failure just after rehydration and before read updates.

Thanks,
Very interesting video!

[mysticmind]

@ppumkin Please take a look at Marten documentation on projections http://jasperfx.github.io/marten/documentation/events/projections/. there are various options for building your projections namely aggregate, inline, async etc. Each would give you varying degree of consistency options from immediate (inline projections) to eventually consistent (async projections).

[kasparkallas]

The ACID-ness comes from the fact that Marten uses PostgreSQL underneath which is a relational database and all the ACID guarantees of it apply to Marten when you are doing operations inside a transaction, even though you are working with "documents".

[ppumkin]

Ahh right. Yes offcourse it is because marten (using lowercase as the repo and website use lowercase) leverages the "advanced" JSON functionality that PostgreSQL provides. I have 0 experience of this which is probably part of the problem

So when I heard documents I was still thinking Mongo being updated by some kind of subscriber which was the eventual consistency issue I was thinking off. Which is my fault mainly because I have been working on greenfield CQRS/ES for a few months and my brain is tuned into that pattern.

But since it writes the JSON into a transactional based database that actually makes allot more sense now.

I failed to understand this because I am heavily from a MSSQL background which, as was explained NET CONF 18 does not have these nice JSON features cannot be used. So I failed to make the link between JSON as a Document in PostgreSQL and Document as in NoSQL DB's

[jeremydmiller]

Sounds like the question is answered, and I'm closing