service层互调，两个都有事务回滚，都标记了@Transactional，如果出现异常抛出，不回滚是什么原因

如果在service层互调中，两个方法都标记了@Transactional注解，并且都抛出了异常，但是事务没有回滚，可能是因为以下原因：

1. 异常被catch了：如果异常被catch了，那么@Transactional注解就不会起作用，因为事务只会在抛出未被catch的异常时才会回滚。

2. 事务传播机制：事务的传播机制定义了一个事务方法如何在另一个事务方法调用期间进行交互。如果两个方法的事务传播机制不匹配，那么事务可能不会回滚。比如，如果一个方法使用了REQUIRED_NEW事务传播机制，而另一个方法使用了REQUIRED事务传播机制，则内部方法的异常不会影响外部方法的事务回滚。

3. 数据库存储引擎：如果你的数据库存储引擎不支持事务回滚，事务就不会回滚。在这种情况下，你需要更改存储引擎或使用其他的数据库。

4. 代码逻辑问题：最后，事务没有回滚可能是因为你的代码有逻辑问题。你可以检查你的代码逻辑是否正确，并确保你的方法在抛出异常时标记为回滚。

综上，如果事务没有回滚，你可以检查以上原因并进行相应的更改。如果你仍然无法解决问题，请提供更多的信息，以便更好地帮助你解决问题。

相关问题

写一个微服务互调的例子

假设我们有两个微服务，一个是订单服务，另一个是库存服务，它们需要相互调用以完成业务逻辑。以下是一个简单的例子：

订单服务(Order Service)提供了一个创建订单的API，它需要调用库存服务(Inventory Service)来检查库存是否充足。如果库存不足，订单创建将失败。

库存服务提供了一个检查库存的API，它需要接收一个商品ID作为参数，并返回该商品的库存数量。

以下是两个微服务之间的互调流程：

1. 客户端调用订单服务的创建订单API，并提供商品ID和数量作为参数。

2. 订单服务接收到请求后，调用库存服务的检查库存API，检查该商品的库存是否充足。

3. 库存服务接收到请求后，查询数据库获取该商品的库存数量，并返回给订单服务。

4. 订单服务根据库存数量判断订单是否可以创建。如果库存充足，则创建订单并返回成功响应；否则返回失败响应。

在这个例子中，订单服务和库存服务是两个独立的微服务，它们通过API相互调用以完成业务逻辑。这种微服务架构可以提高系统的可扩展性和灵活性，同时也可以降低开发和维护的成本。