Home/ Questions/Q 8205199
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-07T08:08:34+00:00

I am trying to implement transactions for distributed services in java over REST. I

  • 0

I am trying to implement transactions for distributed services in java over REST. I have some questions to ask.

  1. What happens when resources reply affirmatively and in phase 2 they fail to commit?
  2. I tried to search but unfortunately I could not find a proper answer to what happens when rollback fails in 2PC protocol. I know that its a blocking protocol and it waits for response for infinite time, but what happens in real world scenario?
  3. what are the other protocols for distributed transaction management?
  4. I read about JTA for transaction implementation, but is there any other implementation which can be used to implement transactions?
    Any reply will be helpful. Thanks in advance.
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I don’t have answers to these questions but I created a specific method for my specific case. So posting here if some one need transactions for the same cases.

    Since In my case there is no change to current entries in database (or indexer, which is also running as a service) but there were only new entries in system at different places, so the false failures were not harmful but false success were. So for my particular case I followed following strategy:

    i. All the resources adds a transaction id with the row in database. In first phase when coordinator ask resources, all resources makes entries in database with transaction id generated by coordinator.

    ii. After phase 1, when all resources reply affirmatively that means resources have made changes to database, coordinator makes an entry in it’s own log that transaction is successful and conveys the same to resources. All resources makes the transaction status successful in the row of data inserted.

    iii. A service run continuously to search the database and correct the transaction status by asking the status from coordinator. If there is no entry or failure entry, transaction returns failure status, and same is updated on service. When fetching data, if there is an entry in database which has failure label, then it always checks the transaction status with coordinator, if there is no entry of failure it filters the results. Hence those data entries are not supplied for which there is no information or there is failure information. So the outcome is always consistent.

    This strategy provides a way for atomicity for my case.

    • 0