search

pmwkaa / serenity

Disk storage and real transactions under Redis compatible protocol.
Other
197 stars 10 forks source link

Why not just use `MULTI`, `EXEC`, and `DISCARD`? #6

Open stuartpb opened 9 years ago

stuartpb commented 9 years ago

Why does Serenity have its own BEGIN, COMMIT, and ROLLBACK commands for transactions? Why not copy Redis's existing transaction semantics?

pcdinh commented 9 years ago

I think that it is because ACID transaction is different from atomicity. From what I read, there is no guarantee that if there is any failure in the middle of the batch, the modifications that is done by previous operations will be discarded.

Correct me if I am wrong

stuartpb commented 9 years ago

Assuming you're talking about errors during execution, It looks like you're right - the atomicity used by MULTI is different from the atomicity model required for ACID:

Errors happening after EXEC instead are not handled in a special way: all the other commands will be executed even if some command fails during the transaction.

There's even an explicit section where they give their rationale for this behavior (it makes sense in Redis's use cases).

That said, in some use cases, sometimes it's worth allowing the parts of a transaction that didn't cause errors, so it would be nice if Serenity supported non-rollback transactions (as well as the ACID-strong parallel set it has now) so I can port my Redis code to Serenity in situations where I just want to use direct-disk-access over RAM, more than I need strong data (I don't know if Serenity plans to support all the same operations as Redis eventually - I hope so).

Glad to hear this is intentional.

pmwkaa commented 9 years ago

Hi, the reason to introduce BEGIN/COMMIT/ROLLBACK is to distinct new interactive multi-statement transactions from the model used in Redis. Interactive means that each operation run within an transaction is not blocked and Serenity allows other client transactions to go in parallel.

In the same time i agree with you, that Redis transaction model (atomic batch commit) also make sense. Same for MSET operation. I believe there should be no problem to implement it in a while, even underlie storage engine also supports that in a efficient way. Thanks)