Проблема транзакции RestCall для сценариев отката - PullRequest
Новая
       91

Проблема транзакции RestCall для сценариев отката

0 голосов
/ 19 апреля 2020

Я использую Spring Boot, и у меня мало опыта по транзакциям ... 

@Service
@Transactional
class FundTransferService {
    public void doSomeFunds(){

        if(realPaymentGateway()){
            //then do db call, to update User Transaction details, WHAT IF SERVER GOES DOWN HERE OR ANY EXCEPTION??
        }

    }

    public boolean realPaymentGateway(){
        //Using Braintree to transfer Funds
    }
}

Выше происходят 2 вещи: paymentGateway (что является вызовом покоя), и если Успех, то только обновление БД с подробностями транзакции пользователя.

Я хочу, чтобы было больше 2 вещей, которые должны произойти. Атоми c, Я имею в виду либо (Отдых, и БД) shud Success, либо откат всего ..

Моя проблема:

Q1) При обновлении сведений о БД из-за какого-либо исключения или из-за отказа сервера может произойти откат только для содержимого БД, но не для RESTCALL ..

Q2) Должен ли я сначала обновить DB, а затем go для PaymentGateway для перевода средств или возврата должен быть правильным? Пожалуйста, предложите мне ..

Надеюсь, вы понимаете мой запрос, так каково решение вышеуказанной проблемы?

Ответы [ 2 ]

1 голос
/ 19 апреля 2020

Вы можете применять транзакции только для транзакционных ресурсов. Как я понял, у вас есть 1 нетранзакционный вход (далее TX) (вызов с запросом платежа) и 2 выхода (удаленный вызов REST без TX и база данных TX SQL). Если вы хотите сохранить согласованность в реальном времени, я могу предложить следующий архитектурный подход: - поместить запрос на оплату в очередь сообщений. MQ Broker должен поддерживать протокол XA для фиксации 2P C (например, ActiveMQ); - ваша служба читает сообщение из очереди, используя XA-соединение, отправляет запрос REST на удаленный сервер и сохраняет данные в БД (которая также поддерживает протокол XA), используя XA-соединение; - если вызов REST не удастся или что-то еще, вы откатите изменения и начнете с обработки запроса оплаты из очереди снова. Кстати, ваш удаленный ресурс REST должен быть идемпотентным;

Если вы используете нетранзакционные ресурсы, нет способа сохранить его согласованным. Кроме того, вы можете найти информацию, например, на сайте Atomikos для использования 2P C.

1 голос
/ 19 апреля 2020

Вы не можете атомарно делать то, что хотите, например охватывать распределенную транзакцию, потому что Braintree - это служба REST вне вашего контроля.

Однако вы можете позвонить в Braintree и впоследствии обновить свою базу данных. соответственно. Таким образом, между вашим вызовом «мозг-дерево» и транзакцией транзакции существует минимальное временное окно, в котором ваш сервер неожиданно «убивается», но в рамках этого ответа нет простого пути.

У вас также может быть какой-то журнал записи с опережением, в котором вы пытаетесь вспомнить, какую службу REST вы будете вызывать, а затем согласуетесь с фактическими вызовами REST, которые произошли, но это немного сложнее и, возможно, излишне.

...