Estou estudando o Hystrix, e pelo que entendi, não posso anotar um mesmo método de uma classe com @HystrixCommand (do Hystrix) e @Transactional (controle de transação do Spring), pois o Hystrix executa o método em thread separada e com isso o @Transactional anotado junto com @HystrixCommand é ignorado (transação não é aberta)
Eu poderia invocar o método A anotado com @HystrixCommand, em seguida invocar o método B de outro bean anotado com @Transactional (nesse momento uma nova transação irá ser iniciada), porém percebi (e confirmei com pesquisas na internet) que esse comportamento abaixo ocorre:
1º Método A anotado com @HystrixCommand é invocado
2º Método A invoca método B de OUTRO bean, anotado com @Transactional, e esse método B realiza uma alteração na base
3º A execução volta para o método A (@HystrixCommand), um timeout ocorre no método A, e mesmo que uma exceção seja lançada, o método B não é "notificado" dessa exceção e com isso a transação iniciada no método B não sofre rollback
Pelo que entendi, esse comportamento se deve pelo fato do Hystrix executar seu método em thread separada
Com isso, qual é a melhor estratégia de mercado quando deseja trabalhar com Hystrix e transações do Spring, de maneira que uma exceção no Hystrix realize um rollback nas transações?
É possível e boa prática de mercado algum mecanismo do Hystrix manipular a transação de outra thread (outro bean) invocado?
Ou a melhor estratégia é fazer uso do método fallback do Hystrix para indicar nesse método execuções na base que desfaçam as alterações (sem de fato um rollback, e sim novas instruções em base para desfazer alterações)?
Um receio nessa estratégia é por exemplo o método fallback do Hystrix ter algum erro, e não conseguir de fato desfazer as alterações
Eu poderia retornar o ID do recurso processado de maneira incompleta na requisição, com um status que induza a quem invocou a requisição a realizar outra chamada para cancelar a alteração, mas e se quem invocou essa execução não conseguir receber com sucesso a resposta (por qualquer motivo, timeout por exemplo) e assim sequer tiver o ID do recuso em mãos para invocar um serviço que desfaça as alterações (terei assim uma inconsistência em minha base e também nos demais sistemas que enviei essa informação)
