Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Serializable by default doesn't seem feasible when you really dive into the concept.

"Serializable" is a system property that describes how two or more transactions will take effect. In this context, I would define "transaction" as a business activity with a clear beginning, middle & end and exhibiting specific, predictable data dependencies. Without any knowledge of the transaction type(s) and their semantics per the business domain, it would be impossible to make assumptions about logical ordering of anything.

SQLite is the closest thing to what you are asking for. All writes are serialized by default, but this is probably not what you really want. We can ensure multiple concurrent connections don't corrupt the data files, but we aren't achieving anything in business terms with this.



transaction in the way everyone else here is using it is referring to the primitive provided by the database which gives certain guarantees (depending on isolation level) wrt reads and writes.

Even in the context of "transaction" the business activity, they are an extremely useful tool for building up exactly the kind of sequencing and dependency guarantees you refer to.


> Serializable by default doesn't seem feasible when you really dive into the concept.

I was expecting you'd argue for a weaker isolation level than serializable, but then you said:

> Without any knowledge of the transaction type(s) and their semantics per the business domain, it would be impossible to make assumptions about logical ordering of anything.

Serializable isolation level only guarantees some total order of transactions, and yes, it doesn't guarantee that the order will be exactly what you want (e.g. first come, first serve). So, are you now suggesting strict serializability [1], then?

[1] https://jepsen.io/consistency/models/strict-serializable




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: