Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The get is not really "transactional"; if a transaction only contains reads, then committing the transaction doesn't actually do anything. Executing a read in a transaction guarantees just one thing: if the value the read returned is not the most current value any more at the time that any <em>writes</em> in the transaction are applied, the transaction will abort and none of the writes will have happened.</p> <p>So, the following sequence of events is allowed to happen:</p> <ol> <li>Start transaction 1.</li> <li>Inside transaction 1, you read entity A and it returns state A1.</li> <li>Inside transaction 1, you update entity A from state A1 to state A2.</li> <li>When committing transaction 1, it fails with one of the mentioned exceptions.</li> <li>Start transaction 2.</li> <li>Inside transaction 2, you read entity A and it returns state A1.</li> <li>Transaction 1 is applied to the datastore in the background, changing A from state A1 to state A2.</li> <li>End transaction 2 (no commit, as there were no writes).</li> </ol> <p>But, this sequence of events is different:</p> <ol> <li>Start transaction 1.</li> <li>Inside transaction 1, you read entity A and it returns state A1.</li> <li>Inside transaction 1, you update entity A from state A1 to state A2.</li> <li>When committing transaction 1, it fails with one of the mentioned exceptions.</li> <li>Start transaction 2.</li> <li>Inside transaction 2, you read entity A and it returns state A1.</li> <li>Inside transaction 2, you update entity A from state A1 to state A3.</li> <li>Transaction 1 is applied to the datastore in the background, changing A from state A1 to state A2.</li> <li>Transaction 2 now <strong>will not commit successfully</strong>, because the write it's about to apply is based on an outdated version of entity A. It will fail and A will be left in state A2.</li> </ol> <p>So, with your step 4 added to the question, you are in the second sequence of events here. It's possible that the get in step 3 returns None even though the entity does exist, but it's <em>not</em> possible for the subsequent write to succeed in that case: the transaction is out of date and thus cannot commit. The transaction will be retried, and the second time around, the get will return the object written in step 1, which is what you wanted.</p> <p>So the very short answer is: yes, it <em>can</em> return a stale value, but it's guaranteed that if the result was stale, a subsequent write to that entity in the same transaction will fail, so this should not actually cause a problem.</p>
    singulars
    1. This table or related slice is empty.
    1. POIs it possible for a transactional db.get() to return a stale result if a recent transaction raised a "special" exception?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USTorne
    1. USTorne
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POIs it possible for a transactional db.get() to return a stale result if a recent transaction raised a "special" exception?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTBountyClose
    1. COThanks @Torne! I edited my question to add step 4. If step 3 returns None (which means it doesn't exist), then I create it. I'm using that entity to make sure that transactions are never run twice because my operations are not really idempotent. My question is that is there a possibility for the step 3 `db.get()` to return `None` when it actually was already created through that delayed transaction occurrence, then proceed to commit everything in the transaction successfully? Thanks!
      singulars
      1. PO
      1. USAlbert
    2. COEdited answer to clarify, but the direct answer to your comment is "no, it will fail to commit" :)
      singulars
      1. PO
      1. USTorne
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload