Flexible retry backoff policies #182
Conversation
|
This change is |
MattWhelan
force-pushed
the
backoff
branch
2 times, most recently
from
3034fdf to
d7039d1
Compare
Extends the existing retry limit mechanism to allow for delays between retries. Includes implementations for fixed delays and exponential backoff.
|
We haven’t implemented this because cockroachdb-go uses save point based retries and because of savepoint-based retries, a transaction can continue holding locks in between retries. So that means with exponential backoff, you'll be holding locks for longer, thus putting the app at even greater risk of contention. If you could show us that this is not the case with backoffs, we will consider adding this! Thanks! |
I just pushed 9dda97b. Could you take a look at that? I'm not sure what all the implications are of separating the database transaction lifecycle from the |
| } | ||
|
|
||
| // Vargo converts a go-retry style Delay provider into a RetryPolicy | ||
| func Vargo(fn func() VargoBackoff) RetryPolicy { |
There was a problem hiding this comment.
I'm wondering if we could think of a different name to go with here. Users of cockroach-go who don't already know about the sethvargo/go-retry library may be confused to see this.
There was a problem hiding this comment.
I'm open to suggestions. I was trying to build an explicit integration without adding a transitive dependency.
| if restartErr := tx.Exec(ctx, "ROLLBACK"); restartErr != nil { | ||
| return newTxnRestartError(restartErr, err) | ||
| } | ||
| if restartErr := tx.Exec(ctx, "BEGIN"); restartErr != nil { |
There was a problem hiding this comment.
This seems like it could have issues. Some libraries may not like it if we use the transaction after rolling it back. For example, I see this in the pgx code where it returns an error if you try to use a transaction that was already rolled back: https://github.com/jackc/pgx/blob/ecc9203ef42fbba50507e773901b5aead75288ef/tx.go#L205-L224
There was a problem hiding this comment.
It returns an error if you use a transaction object that has the closed flag set. Since we're not doing that, it ought to be ok, I would expect.
Extends the existing retry limit mechanism to allow for delays between retries. Includes implementations for fixed delays and exponential backoff.