Clojurians Log v2

serializable

added in book

Does starting a transaction lock out other transactions until it completes? Or are transactions (via the callback or macro) basically just datomic tx fns with a different syntax?

it does

not sure what the second question is about.

transaction is wrapped in with-transaction internally. so it is essentially a LMDB transaction, which is serialized

I see, so txns via callbacks basically work the same way as txn fns, there's no performance trade off between them?

no difference, there is only one type of write transaction. whatever form, eventually, they becomes a LMDB txn

So basically the difference is just syntax

I don't think datomic has with-transaction, the semantics are quite different.

datomic is immutable, the idea of txn there is different from usual sense

so I won't compare datalevin with datomic

Datomic only has transaction fns, but but the approach for serializing transactions seems to be the same: at the start of a transaction, writes are locked, and they're unlocked once the transaction succeeds

so they're also fully serialized

yes, in that sense, it is the same, but within the transaction, the read/write are handled quite differently

How so?

in datalevin, inside a transaction, later reads can read prior writes

in datomic, there's no prior or later stages

That's true

You can emulate it with speculative transactions, but yes that part of the model is different

datomic behavior would be considered surprising for some users

Right

In datalevin, do transaction fns work the same way they do in datomic? I.e. there's no way to read prior writes, they just return tx data?

you can read your writes inside the txn

Right, but you can't write in a tx fn (udf-based, interned, or inline), you just return tx-data

so you can write your txn fn in a normal stateful way

oooh interesting

so your tx-fn could return nil and statefully call transact!

what you do in a custom tx function is up to you, it may have side effect, datalevin doesn't care. it only cares about db read/write. you can do whatever else. like some people do in sql

Got it, so there's not the same contract where tx-fns have to return tx-data

The "different syntax" thing was in reference to how in datalevin, doing a transaction via a transaction fn vs via with-transaction does the exact same thing under the hood (as far as I understand), so there's no performance tradeoffs between the different methods of doing transactions. Is that correct?

correct

a nested txn inside a txn will be using the outer txn, no new txn is created

so whatever you do ,there's only one txn at a time

BTW, do you mind to be added to the acknowledgment as reviewer? I would need your full name for that 🙂

For sure! Max Rothman

It might be a good idea to have a chart or something contrasting the different txn methods so readers know what's the same and different between them

Will do