0

我们有一个需要并行化的Websphere Java EE应用程序,我们正在寻求使用这种并行化程序,其中包括CommonJ work components使用common-j组件进行事务管理

每个'线程'都需要它自己的数据库视图。其中大部分是预取的,但仍需要到数据库才能获得一些。我们预计所有这些线程的整体工作持续时间将会“很长”(即足够的时间来改变底层数据)。

因此,我们需要确保应用程序正在使用的数据的隔离以及在线程工作过程中查询的数据。

看来,确保这一点的唯一方法是进行“全局”事务并使用XA事务。但是,如果可能的话,我们希望避免这种复杂性(和开销),并且正在寻找想法或替代方案:任何想法?

另外,Common-J工作组件支持容器管理事务的程度如何(如果有的话)?

@Karl:也许我只是想开销。我们的想法是,XA事务和消息传递会产生开销,共享J事务组件共享事务可能会避免? 正在操作的数据集将有> 300k不同的数据行,每个数据行需要执行大约100次计算。尽管这些可以划分到不同的线程上运行在共享的,缓存的只读数据上,但复制到/读出队列的比较内存开销看起来是过高的。你会同意吗?

@Karl:每个实体的数十毫秒到几百毫秒。我们还专注于将逻辑处理作为一项单独的任务加以改进。
当需要所有线程在单个数据库中具有统一的数据视图时,是否需要使用XA事务?我对此的回答是每个线程都需要自己的JPA EntityManager(例如连接),并且需要XA来协调其访问。
但是,如果我可以做到这一点没有XA那么那么更好,不是吗?

+0

我想你会感到惊讶XA和消息的开销多低是WAS,听起来更像是我会更担心的逻辑及时处理数据。你认为什么样的时间表是可以接受的,你认为1个实体的处理会花多长时间?你也可以将非常简单的WAS集群化。卡尔 – Karl 2009-04-23 08:43:38

回答

1

在WAS中,您发现有关XA事务的复杂情况?通过它的声音,如果您担心数据完整性,XA事务听起来像是一个不错的选择。

当谈到在WAS中创建和管理自己的线程时,它会变得有点讨厌,我会尽量避免管理自己的线程。一种可能的做法是将数据发布到队列或主题,并有大量的多个并发侦听器从队列中接收。这样您可以配置并发性并让容器管理线程。

卡尔