idea seata tcc项目debug启动出现ArrayIndexOutOfBoundsException异常

idea seata tcc项目debug启动程序的时候出现SignatureParser的 java.lang.ArrayIndexOutOfBoundsException异常。在之前的idea seata at模式的时候,debug功能是正常的,run功能也是正常的。

以debug方式启动,会出现异常和断点,代码执行被中断,以run正常运行方式启动时,程序可以正常启动。在增加tcc模式后,使用了java代理,初步判断,是该原因引起。从异常发生的位置来看,是jdk的代码中,怀疑和业务代码无关。

代码位置:

异常信息:

选择从该断点继续执行,后续会重复在此位置中断。即使不断继续执行,很快又会遇到其它的异常断点,导致程序没有办法调试。

选择菜单"Run"-->"View Breakpoints"进行查看断点。

 

 从断点界面,可以看到java.lang.RuntimeException启用。

取消java.lang.RuntimeException前面的选择。

再次以debug启动,程序可以调试方式运行了。

代码断点和调试功能也正常了。

综合上述信息来看,tcc模式中使用了java代理以后,对idea针对debug模式设置的默认断点规则有一定的影响,此时不适合针对java.lang.RuntimeException设置断点。通过修改配置,重新以debug运行的实际效果来看,也印证了这一点。

seata(Simple Extensible Autonomous Transaction Architecture)是一种开源的分布式事务解决方案,它提供了基于TCC(Try-Confirm-Cancel)的分布式事务处理模式。 假设我们有一个电商系统,其中涉及订单和库存两个服务。订单服务负责创建订单并扣除相应商品的库存,而库存服务则负责记录商品的库存数量。在这种情况下,如果订单服务成功创建了订单但库存服务因为某种原因失败了,有可能会导致订单和库存不一致。 为了解决这个问题,可以使用seataTCC模式。首先,订单服务在尝试创建订单时会对库存服务发送“尝试扣除库存”的请求(Try)。如果库存服务成功扣除了库存,则订单服务会确认订单(Confirm);如果库存服务失败了,则订单服务会取消订单(Cancel)。 具体来说,在订单服务中,会有一个“Try”方法用于尝试创建订单和调用库存服务的“Try”方法;如果“Try”成功,则会有一个“Confirm”方法用于确认订单的创建;如果“Try”失败,则会有一个“Cancel”方法用于取消订单的创建。在库存服务中也类似地定义了“Try”、“Confirm”和“Cancel”方法。 通过使用seataTCC模式,我们可以保证订单和库存的一致性,即使在订单服务和库存服务之间出现了故障或错误。这样,我们就可以避免因为分布式事务导致的数据不一致问题,提高了系统的可靠性和可维护性。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值