9
votes

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?

1
good question, it's not even documenteduser1431972
Something not documented in the GAE docs? Shocking. At least if a GAE team member answers the question here someone will be able to find it with a Google search.Roman Levin
@RomanLevin I don't find it shocking at all... btw the datastore API Reference link from the accepted answer stopped working (not shocking)themihai

1 Answers

3
votes

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.