TM timeout and max-time

The TransactionManager's participants provide easy ways to control per transaction timeouts. One can add a TIMESTAMP entry at the beginning of the transaction, and then have each participant control how it's going, so to speak. If the transaction has spent more than a threshold amount of time, it's better to abort the transaction right away because the client (i.e. POS device) probably has expired the transaction already and it's not waiting for our response anymore.

We can do that on each participant, or you can have a general-purpose timeout participant that you can place here and there.

But because this is a common use case, to encourage its use, in jPOS Next the TransactionManager honors a couple of new attributes at the participant level:

• timeout
• max-time

e.g.:

  ...
  ...
  <participant class="org.jpos.jcard.CheckFields">
   <property name="mandatory" value="PCODE,7,11,12,AMOUNT,PAN,41" />
  </participant>
  <participant class="org.jpos.jcard.SelectCurrency" />
  <participant class="org.jpos.jcard.CreateTranLog" timeout="1000" max-time="5000">     
   <property name="capture-date" value="capture-date" />
   <property name="checkpoint"   value="create-tranlog" />
   <property name="node"         value="${jcard.node:99}" />
  </participant>
  ...
  ...

In this example, three things can happen:

• if, by the time the TM reaches the CreateTranLog participant, the transaction has taken more than 5000ms thus far, the participant is not called, and the transaction continues with the ABORTED route.
• If the partitipant takes more than 1000ms to process, even if it has returned PREPARED, we coerce the response to ABORTED.
• If max time, at the end of the participant is greater than 5000ms, we also coerce the response to ABORTED.