MDB 上的竞争条件：哪种是处理它的最佳方法？
我有一个基于 MDB、Spring 集成和 JPA 的事件驱动应用程序以实现持久性。 该应用程序部署在 weblogic 10.3 上，具有 max-pool-size 默认值 (16)。
我的应用程序需要处理一些修改数据库的消息。 想象一下，我有一个用例，我必须处理一些消息，这些消息的逻辑需要插入域对象（如果不存在）或更新它（如果存在）。
因此，我修改数据库的组件检查对象是否存在，然后在 JPA 上调用合并。 由于当我在 dao 上调用合并时并行执行两条并发消息，因此 JPA 会触发两条插入语句，因为对象尚未持久化，因此只有其中一条正确执行。
在事件驱动的应用程序中是否有一种模式可以处理这种“竞争条件”？
亲切的问候 马西莫
I have an event-driven application based on MDB, spring integration and JPA for persistence.
The application is deployed on weblogic 10.3 with a max-pool-size default value (16).
My application need to handle some messages that modfies DB.
Imagine that I have use case where I have to handle some messages that for their logic need to insert a domain object if it does not exist or update it if it exists.
So my component that modifes the DB check if the object exists or not and then call the merge on JPA.
Since two concurrent messages are executed in parallel when I call the merge on dao, JPA triggers two insert statement since the object is not yet persisted and so only one of them is correctly executed.
Is there a pattern to handle this kind of "race condition" in an event-driven application?
Kind regards
Massimo
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
最简单的解决方案是捕获第二次插入抛出的异常，然后再次调用合并，这应该执行更新。
或者，您可以尝试在
SERIALIZABLE事务隔离中执行合并，这应该确保第二个合并被阻止直到第一个完成，然后第二个应该执行更新。整个场景的主要问题是，如果您有多个并发事件需要修改给定的实体，那么您如何确保以正确的顺序执行它们？您肯定需要按顺序处理这些，而不是同时处理？如果您使用并发事件使用者，则顺序将是不确定的。
The simplest solution is to catch the exception thrown by the second insert, then call
mergeagain, which should perform the update.Alternatively, you could try performing the
mergeinSERIALIZABLEtransaction isolation, which should ensure that the secondmergeis blocked until the first one has completed, and the second one should then perform an update.The main problem with this whole scenario is that if you have multiple concurrent events coming in which entail modifying a given entity, then how do you ensure that you're executing them in the correct sequence? Surely you need to process these sequentially, rather than concurrently? If you use concurrent event consumers, the order is going to be non-deterministic.