Java消息驱动Bean（MDB）同步数据库更新问题
我有一个 java 批处理进程，它将消息处理发布到 MQ。与队列关联的 MDB 处理消息。每条消息将有 10 条记录。我需要更新数据库表来跟踪处理的记录、成功的和失败的记录。每批运行的表中只有一行。所以问题是，由于 MDB 的多个实例都在尝试更新，因此我们面临并发问题。我们也尝试过行级锁定。但问题仍然存在。
我正在寻找一种解决方案，可以跟踪java端的计数器，然后在达到特定阈值后进行一次更新。假设发布了 500 条消息。每条消息处理 10 条记录。 MDB 应在处理此消息中的所有记录后更新此计数器。然后计数器将生成一个线程（如果满足阈值）来更新数据库。
请让我知道我可以选择哪些选项。
应用程序服务器 - Z/OS 上的 WAS 5.6、DB2 9.1。通过 SP 访问 DB2。
谢谢！
I have a java batch process which publishes message processing to MQ. MDB associated with the queue processes the message. Each message will have 10 records. I need to update a database table to keep track of the records processed, successful and failures. There will be only one row in table for each batch run. So the problem is that since multiple instances of MDB are trying to update, we are facing concurrency issues. We tried with row-level locking as well. But the issue still exists.
I am looking for a solution where I can keep track of the counter on the java side and then do a single update after reaching certain threshold. Lets say 500 messages were published. Each message processes 10 records. The MDB should update this counter after processing all records within this message. The counter will then spawn a thread (if threshold is met) that will update the database.
Please let me know what options are available to me.
App Server - WAS 5.6, DB2 9.1 on Z/OS. Access to DB2 is through SP.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您是否尝试过完全在数据库服务器上进行更新？例如：
数据库服务器应该能够像这样管理并发更新语句。
Have you tried doing the update entirely on the DB server? For example:
The DB server should be able to manage concurrent update statements like this.
最简单的解决方案是仅运行一个 MDB 实例，这样并发问题就会消失。
这会有点慢，因为您将一次进行 10 个数据库更新，而不是您建议的 500 个，但除非这是一个问题，否则我会保持简单。
The simplest solution would be to have only a single MDB instance running and your concurrency problem disappears.
This would be a little slower, since you will be doing DB updates of 10 at a time instead of your proposed 500, but unless this is a problem, I would just keep it simple.