Transaction isolation in google app engine

Question

In Google App Engine the transaction isolation is said to be SNAPSHOT isolation, where you do not see previous deletes or puts within the transaction itself, but only the state of the datastore when the transaction began (https://developers.google.com/appengine/docs/python/datastore/transactions). In an older article it says that the transaction level is actually SERIALIZABLE (https://developers.google.com/appengine/articles/transaction_isolation).

The Google Test Compatibility Kit (TCK) shows that it is indeed SNAPSHOT isolation, but in the aforementioned article it says "Inside transactions, on the other hand, the isolation level is SNAPSHOT by default, with the option of changing to SERIALIZABLE".

My question is, how do I enable the isolation level to become SERIALIZABLE?

Answer 1

You can see how to change the isolation level in the BeginTransaction API Reference. It is currently only configurable in the Google Cloud Datastore HTTP API and it defaults to SERIALIZABLE for all of the App Engine SDKs. However I do not think this will do what you want it to do.

SNAPSHOT vs SERIALIZABLE controls transaction isolation or how concurrent transactions interact with each other. It does not control how a transaction interacts with itself (though in some systems these two things are conflated).

In the Datastore, setting SERIALIZABLE will not make it so a transaction will see its own uncommitted mutations. It only means that concurrent transactions will collide if their read and write patterns are not valid when serialized. For example, the following two transactions will necessarily collide when using SERIALIZABLE isolation:

TX1: READ A, WRITE B'
TX2: READ B, WRITE A'

As neither of these two orderings are possible:

READ A, WRITE B', READ B (conflict), WRITE A'
READ B, WRITE A', READ A (conflict), WRITE B'

However, these transactions will not necessarily collide with SNAPSHOT isolation.

Both SNAPSHOT and SERIALIZABLE read from a 'snapshot' of the data, as if the data is changed in a way that conflicts with transactional isolation guarantees while the transaction is running, the transaction cannot be committed.