You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DISCUSSION: Is there a way for a Transaction to indicate success/failure from __exit__ #496
Currently, there is no way to determine if this occurs. It's unclear what a way forward would look like but in ndb transactions have retries and can createFuture objects which know about the success or failure.
The transaction package has a concept of a "doomed" transaction: one which is in a hosed state, from which it can never be committed. Having our code fail inside __exit__ would be something like that with two sharp edges:
Failing while committing is actually more reasonable: the back-end might actually barf here.
Failing while aborting is a real problem: which exception should surface?
FWIW, the Zope transaction's "two-phase commit" tries to deal with the problems of the first, by breaking up the "commit" into slices, for distribution across multiple resource managers (e.g., a database and a mail-sender). For each of the following methods, the transaction calls each resource manager in turn):
tpc_begin (can we commit?)
commit(do the work, but don't finalize)
tpc_vote (were there problems? last chance to back out)
tpc_finish (finalize; this must never fail: if it does, we've lost consistency)
tpc_abort (called if any RM raises from tpc_vote: must never fail).
There seem to be less than 8 states (implied by 3 bools) but more than 4, so maybe there is a better way to get the information to answer the questions:
txn is in progress or not?
txn has already been "used"?
txn finished in commit (success) or rollback (failure)
You also need some way to get auto allocated keys back from the transaction right? Could this be incorporated into the method which indicates failure or success?
Activity
tseaver commentedon Jan 7, 2015
The transaction package has a concept of a "doomed" transaction: one which is in a hosed state, from which it can never be committed. Having our code fail inside
__exit__would be something like that with two sharp edges:FWIW, the Zope transaction's "two-phase commit" tries to deal with the problems of the first, by breaking up the "commit" into slices, for distribution across multiple resource managers (e.g., a database and a mail-sender). For each of the following methods, the transaction calls each resource manager in turn):
tpc_begin(can we commit?)commit(do the work, but don't finalize)tpc_vote(were there problems? last chance to back out)tpc_finish(finalize; this must never fail: if it does, we've lost consistency)tpc_abort(called if any RM raises fromtpc_vote: must never fail).dhermes commentedon Jan 8, 2015
For the most part the backend handles this.
It seems a concept of "doomed" would be nice since it would make it so that.
I was thinking something simple along the lines of
There seem to be less than 8 states (implied by 3 bools) but more than 4, so maybe there is a better way to get the information to answer the questions:
txnis in progress or not?txnhas already been "used"?txnfinished incommit(success) orrollback(failure)elibixby commentedon Jan 8, 2015
You also need some way to get auto allocated keys back from the transaction right? Could this be incorporated into the method which indicates failure or success?
Tracking status of Transaction as well as success / failure.
Tracking status of Transaction as well as success / failure.
Drop Python 3.4. (googleapis#496)
build(deps): bump cryptography from 38.0.3 to 39.0.1 in /synthtool/gc…
10 remaining items
build(deps): bump cryptography from 38.0.3 to 39.0.1 in /synthtool/gc…
chore(main): release 0.17.3 (#496)
feat: support quota project override via client options (#496)
feat: migrate to pyproject.toml (#496)
chore: bump urllib3 from 1.26.12 to 1.26.18 (#496)
docs: add summary_overview template (#496)
feat: allow 'Collection.where(__name__, in, [hello, world])' (#501)
chore: Adding support for pytest-xdist and pytest-parallel (#496)
fix: fix concurrency bug in redis cache implementation (#503)
chore: Adding support for pytest-xdist and pytest-parallel (#496)
feat: encrypted mtls private key support (#496)
chore(deps): update dependency google-cloud-pubsub to v2.8.0 (#496)
chore: Migrate gsutil usage to gcloud storage (#496)
feat: support Partitioned DML (#541)
fix(deps): update minimum dependency versions to pick up bugfixes (#496)