1

Currently my code makes a series of updates to some resource via a REST API but I also have some "rollback" logic that basically updates the resource to its original state before my updates if some kind of error happened. So in psuedo-code, the logic looks like:

public void doUpdate(Resource r) {
   // do a GET to get the latest eTag
   // make PUT call with eTag to do actual update
}

public void myLogic(Resource r) {
  Resource original = r;
  Resource copy = r.copy();
  try {
   doUpdate(copy);
   // do something to copy
   doUpdate(copy);
   // do some more things to copy
   doUpdate(copy)
  } catch (Exception e) {
   // rollback to original version
    doUpdate(original);
  }
}

This is a simplification of my actual code but my question is: Is it more correct to do GET before every update to get the latest eTag(as shown) or should I get the eTag once at the beginning and then "chain" the eTag I get from the prior update for the next update, including the rollback step?

Improve this question
3
  • 2
    Does this answer your question? What is the most accepted transaction strategy for microservices – Dan Wilson Jul 29 '20 at 18:47
  • 1
    You should retrieve the ETag as close to the update as possible and include all updates in a transaction/unit of work. – Dan Wilson Jul 29 '20 at 18:49
  • @DanWilson I think it gives a good overview of the particular architecture I am dealing with with. In my actual code, lot of the intermediate operations that I am doing are in fact other API calls so its impossible to do the updates in a single operation... – Pepria Jul 29 '20 at 19:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.