在提交事务之前传递JMS消息

ewe*_*nli 20 database jms 2phase-commit distributed-transactions java-ee

我有一个非常简单的场景,涉及应用程序服务器(Glassfish)中的数据库JMS.场景很简单:

1. an EJB inserts a row in the database and sends a message.
2. when the message is delivered with an MDB, the row is read and updated. 
Run Code Online (Sandbox Code Playgroud)

问题是有时在数据库中提交插入之前传递消息.如果我们考虑2阶段提交协议,这实际上是可以理解的:

1. prepare JMS
2. prepare database
3. commit JMS
4. ( tiny little gap where message can be delivered before insert has been committed)
5. commit database
Run Code Online (Sandbox Code Playgroud)

和其他人讨论过这个问题,但答案总是如此:"奇怪,它应该开箱即用".

我的问题是:

  • 它怎么能开箱即用?
  • 我的场景听起来很简单,为什么没有更多人遇到类似的麻烦?
  • 难道我做错了什么?有没有办法正确解决这个问题?

以下是关于我对问题的理解的更多细节:

只有在按此顺序处理参与者时才存在此计时问题.如果2PC以相反的顺序(数据库优先,然后是消息代理)处理参与者应该没问题.这个问题是随机发生的,但完全可以重现.

我发现无法在Glassfish文档中控制JTA,JCA和JPA规范中分布式事务中参与者的顺序.我们可以假设它们将在使用它们时按照顺序登记在分布式事务中,但是使用诸如JPA之类的ORM,很难知道何时刷新数据以及何时真正使用数据库连接.任何的想法?

小智 11

您正在体验经典的XA 2-PC竞争条件.它确实发生在生产环境中.

我想到了三件事.

  1. 最后一个代理优化,其中JDBC是非XA资源.(失去恢复语义)
  2. 有JMS时间交付.(故意失去实时)
  3. 构建重试为JDBC代码.(对功能的影响最小)

Weblogic有这种LLR优化可以避免这个问题,并为您提供所有XA保证.

  • @Theo`select*for update`将获取读取行的锁.插入行的第一个tx具有该行的锁定,直到提交tx为止.我们传递消息中插入(但尚未提交)的行的id,如果在提交插入之前实际触发了MDB,则使用`select*where id ='插入的行的id为'update`将暂停第二个tx,直到第一个tx中的行被提交并且可以获取锁定. (3认同)