Request for Eclipse Microprofile-LRA

[Max Grabert]

Hello all,

my colleague Matthias Koch and I have some request regarding the Microprofile-LRA-Spec, related to my question 4.3 you answered here:

1. Is there a way for the compensation method to find out, if it was called because of a timeout or any other error?
   

No the spec just defines the triggers to guarantee atomic outcomes (but we can add it if you think that is something applications would find useful).

Yes, we would find it rather useful. Please add it.

To summarize:

GIVEN: a LRA is being called that is running into a timeout (a timeLimit for the LRA is set).

THEN: The compensatory actions of the participants are triggered. But there is the possibility that LRA actually succeeds, although there was a timeout.

REQUEST: Since we can not identify if the LRA is being cancelled because of a timeout or an error, we have to call the @Status method to detect if the LRA is still running, was successful, or did indeed fail.

(or - if there is no @Status method, the idempotent @Compensate method). This appears to be rather clumsy.

We would feel better if the participants could easily identify in the compensation method if there reason for the trigger was a timeout or not, so unnecessary calls to the LRA are avoided.

Best regards,

  Max Grabert

[Michael Musgrove]

Hi Max,

If the LRA is cancelled, either explicitly by the client or because the time limit was breached then every participant that enrolled in the LRA will be told to compensate. Why does the participant need to differentiate between these two reasons for why an LRA is cancelled, the participant need only be concerned about compensating for any actions it performed while the LRA was active (the purpose of the protocol is to guarantee an atomic outcome).

Note also that the @Status method is meant to be called by the spec implementation to discover when an in progress compensation is finished. The only means by which services can discover the target state of an LRA is by enlisting as a participant and even then there is no mechanism by which he can discover whether or not the LRA successfully cancelled (unlike JTA 2PC transactions we do not provide synchronizations). But do note that if there is a compensation violation (eg if a participant is unable to compensate) then the situation must be logged by the system but we do not provide any API for services to discover that this was the final outcome. If you think that we need to provide "afterCompensation" and "afterCompletion" notifications or provide a query mechanism to discover the current/final state of an LRA then you could raise an issue and we can discuss whether or not it makes sense to provide such features.

[Max Grabert]

Hi Michael,

On Tuesday, 11 June 2019 12:52:28 UTC+2, Michael Musgrove wrote:

Hi Max,

If the LRA is cancelled, either explicitly by the client or because the time limit was breached then every participant that enrolled in the LRA will be told to compensate. Why does the participant need to differentiate between these two reasons for why an LRA is cancelled, the participant need only be concerned about compensating for any actions it performed while the LRA was active (the purpose of the protocol is to guarantee an atomic outcome).

So far so good.

But how is the following example being handled?

Let's assume the LRA consists of several participants, the one (e.g. the last one) being a DB UPDATE statement.
A time limit is specified for the LRA, and unfortunately the DB UPDATE statement takes much longer than anyone would expect. So the compensations methods of the participants are triggered. But the DB UPDATE statement eventually finishes successfully, so data changes occurred that need to be compensated.

Is the @Compensate method of the participant with the DB UPDATE statement now being triggered as well (let's assume it doesn't have a timeLimit set itself)?

I assumed that only the compensation methods of the previous participants are being triggered.

 

Note also that the @Status method is meant to be called by the spec implementation to discover when an in progress compensation is finished. The only means by which services can discover the target state of an LRA is by enlisting as a participant and even then there is no mechanism by which he can discover whether or not the LRA successfully cancelled (unlike JTA 2PC transactions we do not provide synchronizations). But do note that if there is a compensation violation (eg if a participant is unable to compensate) then the situation must be logged by the system but we do not provide any API for services to discover that this was the final outcome. If you think that we need to provide "afterCompensation" and "afterCompletion" notifications or provide a query mechanism to discover the current/final state of an LRA then you could raise an issue and we can discuss whether or not it makes sense to provide such features.

Okay, understood.

Based on the theoretical example described above; let's assume then not a LRA timeLimit was reached, but a timeLimit was specified in a @Compensate method was reached.

But what happens if the participant was able to still change data before that? In a timeout situation you cannot be sure if/what DB/data changes occurred, so then you will have to track every single data change done in the participant somehow, so the compensation method knows if/what compensation actions should be performed. Is that correct?

Thanks a lot for your answers!

Cheers,

   Max

[Michael Musgrove]

All participants will be told to compensate. The usage model is to make some changes and record somewhere what you did (for example issue https://github.com/eclipse/microprofile-lra/issues/15 will allow you to store the data with the implementation of this spec). Typically these changes would be visible to other services. The saved data means you know what to compensate for if the LRA is cancelled.

If the db statement is still running when the compensate call happens and you cannot cancel it then the compensation needs to wait for it to complete and then compensate for the changes made by the db update (note that a compensation does not have to happen immediately so it is okay to wait for the original update to finish). You should be able to track any changes since the participant is defined in the same class/instance that performed the update.

As well as cancelling the running db update, you also have the option of setting timeouts on the transaction that you use to do the db update as well as the compensation time limit which will reduce the probability of problems but, since the LRA model only guarantees eventual consistency there is still a window where other services will see inconsistent changes.

If the participant finds that it is unable to compensate then it MUST report that situation and a compensation violation is logged by the system for resolution by some other application specific component.

So to summarise, it is the responsibility of the application to track its updates and to compensate for them if the LRA is cancelled. 

Also I don't think that knowing whether an LRA cancelled due to a timeout will help you in this situation but we could provide it by supporting synchronizations.

[Michael Musgrove]

To be clear, when I said it is okay for the compensation to wait for the original update to finish, I did not mean wait as in block: the state model for participants includes the state Compensating which the participant can report in a number of ways (by returning a 202 Accepted HTTP status code or by returning a CompletionStage. or by returning a ParticipantStatus value). The implementation will track its progress by periodically checking the status via the @Status method if present and if not will call the compensation method repeatedly until the participant enters one of the end states of the state model (`Compensated` or `FailedToCompensate`).

[Max Grabert]

Hi Michael,

thanks a lot for your quick and elaborate answers, this makes many things much clearer.

Best regards,

  Max Grabert & Matthias Koch

[Michael Musgrove]

Based on your input is it reasonable to say that the following two features would be useful:

- Implement https://github.com/eclipse/microprofile-lra/issues/15 which will allow participant to store compensation data with the implementation of this spec). The saved data means a participant would know what to compensate for if the LRA is cancelled.

- Add an extra callback to notify interested parties about the outcome of an LRA (whether it was closed or cancelled normally or cancelled due to a timeout). I have just raised https://github.com/eclipse/microprofile-lra/issues/164 to cover this.

If anyone would like to see these features please could you vote them up (or down if you think they aren't needed).