3 ms·

I love Datomic because of the way it removes the need to understand these locks completely. With datomic you can reason far more easily about a set of concurren

I love Datomic because of the way it removes the need to understand these locks completely. With datomic you can reason far more easily about a set of concurrent updates than dealing with SQL locking levels. The trade is you are essentially always running with your database as fully serialized writes.

Animats 11y ago
"The trade is you are essentially always running with your database as fully serialized writes." That's a high price to pay. It's easy to do updates serially, and complex to do them concurrently.
akurilin 11y ago
Can that be achieved by setting all writes in postgres to isolation level serializable?
- andrewchambers 11y ago
  Not in the same way. Because the datomic database is immutable queries can take as long as they want and the results will never be inconsistent.
  - lucian1900 11y ago
    Postgres transactions can also take as long as they want and the results will never be inconsistent. The downside to SERIALIZABLE is that conflicts become visible failures to the client, so you have to handle them and retry. Datomic solves this by serialising through the function you pass, but at great latency cost.
    - akurilin 11y ago
      No free lunch.
pkolaczk 11y ago
Concurrent updates get interesting when they are based on reads that happened earlier. Then applying updates atomically doesn't buy you anything - you still need to either lock the object so that noone modifies its state between the read and the update (pessimistic locking), or be prepared to abort an update if a concurrent change to the object is detected (optimistic locking), or to append the update instead of overwriting previous state and eventually resolve / fix later, which is not always possible and may be just as hard as getting the locking right. Additionally, being too optimistic about shared resources management may lead to really bad user experience - like being kicked out at the gate because the flight is overbooked or like being fined for overdrawing your debit-card by offline transactions. You just need to pick your poison ;)

Animats 11y ago

"The trade is you are essentially always running with your database as fully serialized writes." That's a high price to pay. It's easy to do updates serially, and complex to do them concurrently.

akurilin 11y ago

Can that be achieved by setting all writes in postgres to isolation level serializable?

andrewchambers 11y ago
Not in the same way. Because the datomic database is immutable queries can take as long as they want and the results will never be inconsistent.
- lucian1900 11y ago
  Postgres transactions can also take as long as they want and the results will never be inconsistent. The downside to SERIALIZABLE is that conflicts become visible failures to the client, so you have to handle them and retry. Datomic solves this by serialising through the function you pass, but at great latency cost.
  - akurilin 11y ago
    No free lunch.

pkolaczk 11y ago

Concurrent updates get interesting when they are based on reads that happened earlier. Then applying updates atomically doesn't buy you anything - you still need to either lock the object so that noone modifies its state between the read and the update (pessimistic locking), or be prepared to abort an update if a concurrent change to the object is detected (optimistic locking), or to append the update instead of overwriting previous state and eventually resolve / fix later, which is not always possible and may be just as hard as getting the locking right. Additionally, being too optimistic about shared resources management may lead to really bad user experience - like being kicked out at the gate because the flight is overbooked or like being fined for overdrawing your debit-card by offline transactions. You just need to pick your poison ;)