CODEWITHSUNDEEP
google-cloud-platformgoogle-cloud-spanner
hbakkum
hbakkum

Reputation: 73

Detecting when a spanner read timestamp has expired

I am trying to build a cursor based pagination API on top of a spanner dataset. To do this I'm am using the read timestamp from the initial request to retrieve data and then encoding this into a cursor which can then be used to do an "Exact staleness" (https://cloud.google.com/spanner/docs/timestamp-bounds) read in subsequent paging requests.

For example, the processing of a request for the first page looks something like:

Transaction tx = spanner.singleUseReadOnlyTransaction();
tx.executeQuery(statement); // result set containing the first page of data
tx.getReadTimestamp(); // read timestamp that gets returned in a cursor

And for subsequent requests:

 Transaction tx = spanner.singleUseReadOnlyTransaction(TimestampBound.ofReadTimestamp(cursorTs));

I'd also like to return a message to the user when the cursor timestamp has expired (the documentation linked to above states they are valid for roughly an hour) and to do this I have the following code:

try {
   // process spanner result set

} catch (SpannerException e) {
    if (ErrorCode.FAILED_PRECONDITION.equals(e.getErrorCode)) {
        // cursor has expired, return appropriate error message
    }
}

This works fine when manually testing against a long running spanner database. However, in my test code I create a spanner database and then tear it down once the test is complete and in these tests the spanner exception is only thrown intermittently when I use a read timestamp that should definitely be expired (say over a year old). In the cases where no exception is thrown, I get an empty resultset. If I make multiple requests to spanner in my test with this expired read timestamp, eventually the database seems to consistently throw the "failed precondition" error.

Is this behaviour expected for a newly provisioned spanner database?

Upvotes: 1

Views: 630

Answers (1)

oakinlaja
oakinlaja

Reputation: 906

I believe the reason for this behavior is because you are using Read-only Transactions. As explained in the documentation, Read-only transactions always observe a consistent state of the database and the transaction commit history at a chosen point. In your case, the database is created and torn down before and after your test is completed. Hence, no transaction commit history to be observed except after a number of attempts.

Upvotes: 1

Related Questions