Thanks. I see now that if err == nil in the following code snippet, then
the for loop will end. Not sure why I find the effect of this err check
confusing, but I do. Probably its dual-use is the culprit. Return on
happy path (i.e., err == nil) and return on most errors.
if cmt, err := tx.Commit(); err != ErrConcurrentTransaction {
return cmt, err
}
On Sunday, December 27, 2020 at 3:04:32 AM UTC-5 peterGo wrote:
> Jeff,
>
> Retry if err == ErrConcurrentTransaction.
>
> Peter
>
> On Saturday, December 26, 2020 at 10:54:36 PM UTC-5 Jeff wrote:
>
>> I was curious how datastore.RunInTransaction was implemented in
>> comparison to the Transaction method set so I took quick look at the source
>> code. However, I hope I am simply misunderstanding the source code for
>> datastore.RunInTransaction at:
>>
>>
>> https://github.com/googleapis/google-cloud-go/blob/datastore/v1.3.0/datastore/transaction.go#L161
>>
>> I "think" I understand what it is supposed to do. In short, if the
>> transaction fails it should retry a number of times. But, when looking at
>> the code, it appears to return after the first error and only succeed if it
>> runs successfully through the for loop the number of times. Thus,
>> increasing the attempts would actually decrease the chances of successfully
>> committing the transaction as it would need to be successful for each
>> attempt.
>>
>> Hopefully, my interpretation is wrong and someone can explain what is
>> actually going on.
>>
>> Thanks,
>> Jeff
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/cfde25c3-ff2a-4e0a-9a3d-2cad0da349aen%40googlegroups.com.
