7 Replies Latest reply on Feb 28, 2007 9:41 AM by Weston M. Price

    Usage of LastResource Inteface leads to warning

    ypsilon Newbie


      Since I am kind of new to JTA and I have to implement it a at a fairly vital part (payment) of our system I'd like to ask you if I should pay more attention to the following warning

      "Prepare called on a local tx. Use of local transactions on a jta transaction with more than one branch may result in inconsistent data in some cases of failure."

      In short: This error occurs whenever I enlist an XAResource which implements the LastResource interface in the transaction. So the first question is:

      ------> Is this normal?

      (I did not find a way to avoid the message with the LastResource interface implemented, but from what I learned so far that's the way to use the Interface.)

      Since I am interested in any opinion / suggestion I can get here is a more in-depth description:

      There is an external service provider which handles our payments. In order to communicate with that provider the idea was to implement an XAResource which does the communication and thereby ensures that the payment is done when the database transaction is done. The protocol the ServiceProvider uses is somewhat limited when it comes down to error recovery. Because of that it seems to be pretty hard to implement a real, stable XAResource adapter. 1)

      Since I cannot implement a complete XAResource I wanted to implement the LastResource interface. By that I can do all the communication after all prepare() calls are done (in our case only the DB prepare so far.) My guess is that through this the risk of an incosistent state after the end of the transaction is minimized.

      So here comes the second question:

      Any opinions about this solution?


      Thanks in advance

      PS: If one of the developers is reading this here is a suggestion. Put the XID and or class of the resource in this warning. You have no clue how to identify which resource it is that causes the trouble...

      1) The protocol used is fairly simple: first step is to authorize a transaction, second step is to commit the transaction. Both is done via Http. In theory a cancellation request can be done afterwards - but only within a very small timeframe so using that is not really an option.
      Apart from that in some scenarios the first step has to be done outside the transaction.