我应该在这种多线程架构中使用 Hibernate 还是放弃它？答案

【问题标题】：Should I use Hibernate with this multi-threaded architecture or abandon it?我应该在这种多线程架构中使用 Hibernate 还是放弃它？
【发布时间】：2010-07-29 03:36:44
【问题描述】：

我的软件使用多个线程来完成它的工作。有一个管道看起来像这样：

+-----------------+ |+-----------------+ +------------+ ||+-----------------+ +------------+ | | ||| | | | |获取和 | |||工作线程 | |保存 | |饲料工作|--->>||| |--->>|输出 | | | |||工作 | | | +------------+ +|| | +------------+ +| | +-----------------+

每个框代表一个单独的线程。它们之间的箭头是“工作”对象流经的线程安全队列。 “获取并提供工作”线程从数据库中提取等待工作并将其提供给工作线程池。这些工作线程做一些工作，更新工作对象上的状态标志（并将其存储到数据库中）以及产生一些输出对象。输出对象流向“保存输出”线程，在那里它们在数据库中保存和/或更新。

这种架构的目的主要是为了提高排队效率。

我需要“Get and Feed Work”线程拥有自己的数据库会话/连接，以便它可以不断地从数据库中读取、解除阻塞并将该数据提供给工作线程。

每个工作线程还需要他们自己的数据库连接/会话，主要是为了更新他们在数据库中处理他们正在处理的任何任务的进度。这些数据库连接/会话始终是低影响的、不经常更新的。每个工作线程都会产生一些重要的东西，需要插入到数据库中。它不是每个工作线程都执行自己的插入操作，而是将该责任下放到“保存输出”线程。

“保存输出”线程通过批量写入数据库来提高效率 - 批量插入比一次插入要快得多。

我开始认为 Hibernate 可能不适合这种架构。

我发现自己在处理 Hibernate 会话时遇到了很多问题，驱逐、合并、清除、刷新，哦，天哪。

我的架构目前看起来很稳定，但也似乎效率极低。放弃Hibernate而直接使用JDBC会不会更好？

【问题讨论】：

标签： java multithreading hibernate persistence

【解决方案1】：

您可以分离会话之间传递的对象，也可以只传递对象 ID。

【讨论】：

每种方法有优缺点吗？我的自然倾向是在对象离开一个线程时将其分离，并在它到达新线程时将其合并。

【解决方案2】：

休眠会话和从会话加载的对象不是线程安全的，因此它们不能被不同的线程同时访问，但是可以从不同的线程依次访问它们。从您的流程描述来看，线程之间似乎没有重叠，因此您应该可以很好地传递对象和会话。

请确保不要使用线程绑定会话，不要使用SessionFactory.getCurrentSession()

【讨论】：

我正在使用线程本地会话，所以听起来我必须分离。
您可以编写自己的线程本地实用程序类，并在切换到工作线程时将会话绑定到线程。因为 Hibernate 需要获取数据库状态，所以使用分离的对象并合并它们会产生大量的查询。另一个缺点是您失去了使用事务的能力。由于一个工作单元涉及 3 个会话（获取数据、工作、保存数据），一些并发更新可能会介于两者之间。