Stream: implementers
Topic: Failure Behaviour of Transaction Reads
Alexander Kiel (Aug 04 2021 at 08:24):
According the Transaction Processing Rules transaction actions should either fail or succeed completely.
For a transaction, servers SHALL either accept all actions and return a 200 OK, along with a response bundle (see below), or reject all resources and return an HTTP 400 or 500 type response.
For write actions (create, update, delete, ...) this atomicity is clear. However transactions can also contain reads. In the transaction bundle example one can find the statement:
can also do read-only operations.
Note that these do not 'fail' - see discussion on transaction
atomicity for further information
I can't find a section in the documentation that discusses the transaction atomicity particular for reads.
If I post transaction bundles with reads to HAPI, I get a transaction-response bundle with the individual errors in it's entries rather than a complete failure on the post. If I mix reads and writes, a failure on one write will result in a complete failure but failures on reads will result in successful writes and individual failed reads.
So it seems that failed reads don't result in a failed transaction but failed writes do. Is this the expected behaviour? Is there a section in the documentation that makes this behaviour clear?
Lloyd McKenzie (Aug 04 2021 at 21:57):
I think it's reasonable behavior in that reads don't affect state, so their success or failure don't actually impact database state. Do you have a use-case where a read failure should legitimately cause the transaction to roll back? Also agree that having better documentation would be good, so feel free to submit a change request either way.
Paul Church (Aug 04 2021 at 22:01):
That's a tricky one. My gut reaction was that it should fail on the grounds that "something is wrong" in the transaction but I don't know of a use case where it's really necessary to roll back.
Lloyd McKenzie (Aug 04 2021 at 22:04):
I'm not arguing that a server couldn't fail the transaction. Just that it's not necessarily wrong if they don't fail because of an error on a GET.
Alexander Kiel (Aug 05 2021 at 07:40):
@Lloyd McKenzie I had the request from someone to implement the atomic failure behaviour on reads in Blaze. Because the documentation was not super clear, I tested in HAPI and Vonk. Both servers didn't fail on reads.
I like your argument that failing reads do not effect the state of the server. On top of that, in my database architecture which isn't the usual RDBMS, it would be really inefficient to implement a rollback on failing reads. So I will submit a change request.
John Moehrke (Aug 05 2021 at 12:12):
I could see where an operation might be defined this way, but it would be explicitly defined based on use-case and the operations functional need. At the generic transaction level, I would tend to agree with Lloyd that a fail on a GET should not have affected any server state so would not be logical to rollback the transaction. I wonder if those that are looking for this behavior are actually defining something more than just a transaction, they are actually needing an operation?
Last updated: Apr 12 2022 at 19:14 UTC
