transaction serialisability

[Benoit Chesneau]

In the doc i can read that transactions arr handled serially:

« Transactions are submitted to the system's Transactor component, which processes them serially and reflects changes out to all connected peers »

and later it states :

« Since the transactor is not processing queries (they are handled in the peers), no locking is required and the processing is very fast. »

This part I don’t understand. doesn’t the transactor still have to lock for 2 concurrent writes on the same attribute of an entity? Or does it means that all writes are handled sequentially?

benoît

[Benoit Chesneau]

this other quote from the ACID doc seems to describe smth sequential (transactions are queued and handled one byone):

« Datomic is a single-writer system. A single thread in a single process is responsible for writing transactions. The Isolation property follows automatically from this, because there are no concurrent transactions. Transactions are always executed serially. »


But I’m probably wrong since the transactions are afailk very fast...

Benoit

[Timothy Baldridge]

Transactions go into a queue and are executed serially. But if you think
about it, very little of what the transactor does needs to be done on a
single thread. Indexing jobs, can be done in parallel, as well as things
like checking two unrelated constraints. Also (as mentioned in the docs)
never discount how fast a single writer can perform when it's only codepath
is writing. The more specialized a thread of execution becomes the more
things like caches, branch prediction and the like come into play.

So as it turns out, it's pretty hard to run a transactor a full-bore for an
extended period of time, in my experience other limitations pop up sooner.

Post by Benoit Chesneau
this other quote from the ACID doc seems to describe smth sequential
« Datomic is a single-writer system. A single thread in a single process
is responsible for writing transactions. The Isolation property follows
automatically from this, because there are no concurrent transactions.
Transactions are always executed serially. »
But I’m probably wrong since the transactions are afailk very fast...
Benoit
--
You received this message because you are subscribed to the Google Groups "Datomic" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

[Benoit Chesneau]

Transactions go into a queue and are executed serially. But if you think about it, very little of what the transactor does needs to be done on a single thread. Indexing jobs, can be done in parallel, as well as things like checking two unrelated constraints. Also (as mentioned in the docs) never discount how fast a single writer can perform when it's only codepath is writing. The more specialized a thread of execution becomes the more things like caches, branch prediction and the like come into play.

That's right .... One last thing though, what do you mean by "checking relation constraints"? Does it split a transaction in different steps that can be run independently?

So as it turns out, it's pretty hard to run a transactor a full-bore for an extended period of time, in my experience other limitations pop up sooner.
« Datomic is a single-writer system. A single thread in a single process is responsible for writing transactions. The Isolation property follows automatically from this, because there are no concurrent transactions. Transactions are always executed serially. »
But I’m probably wrong since the transactions are afailk very fast...
Benoit
--
You received this message because you are subscribed to the Google Groups "Datomic" group.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
--
“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)
--
You received this message because you are subscribed to a topic in the Google Groups "Datomic" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/datomic/6RziJ26oX3E/unsubscribe <https://groups.google.com/d/topic/datomic/6RziJ26oX3E/unsubscribe>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.