我们的问题是我们正在构建一个复杂的(如同许多对象相互引用)有状态的RIA系统.似乎Hibernate主要用于一次性应用程序 – JSF等.
问题主要是延迟加载.由于在初始化和实际加载惰性集合之间可能存在多个HTTP请求,因此每个事务的会话都是不可能的.一个长期存在的会话(每个应用程序一个)也不能正常工作,因为一旦事务遇到障碍并抛出异常,整个会话就会失效,因此延迟加载的对象会中断.然后有各种各样的东西对我们不起作用(比如隐藏数据持久化来自初始化事务之外的数据).
除了我可怜的解释,最重要的是Hibernate做了我们不喜欢的魔术.看起来TopLink并没有更好,它也是在EJB之上编写的.
因此,无状态持久层(甚至是足够明亮的面向对象的数据库抽象层)是我们最需要的.
有什么想法,还是我要求不存在的东西？
编辑：我很抱歉我的模糊术语,并感谢大家的更正和有见地的答案.那些纠正我的人,你们都是正确的,我的意思是JPA,而不是EJB.
解决方法
@H_301_17@ 如上所述,JPA<> EJB,它们甚至都不相关. EJB 3恰好利用JPA,但就是这样.我们有很多使用JPA的东西甚至没有接近运行EJB.你的问题不是技术,而是你的设计.
或者,我应该说,你的设计并不适合任何现代框架.
具体来说,您尝试通过多个HTTP请求保持事务处于活动状态.
当然,大多数常见的习惯用法是每个请求本身就是一个或多个事务,而不是每个请求都是更大事务的一部分.
当您在同一讨论中使用术语“无状态”和“事务”时,也存在明显的混淆,因为事务本质上是有状态的.
您的大问题是手动管理您的交易.
如果您的事务发生在多个HTTP请求上,并且这些HTTP请求碰巧正在“非常快”地运行,那么您应该不会真正遇到任何实际问题,除非您必须确保您的HTTP请求使用相同的数据库连接以利用数据库事务工具.
也就是说,简单来说,您可以获得与数据库的连接,将其填充到会话中,并确保在事务持续期间,您的所有HTTP请求不仅通过相同的会话,而且通过这种方式实际连接仍然有效.具体来说,我不相信有一个现成的JDBC连接,它实际上可以在故障转移或从一台机器到另一台机器的负载平衡中存活.
因此,简单地说,如果要使用数据库事务,则需要确保使用相同的数据库连接.
现在,如果你的长期运行事务中有“用户交互”,即你启动数据库事务并等待用户“做某事”,那么,很简单,这种设计都是错误的.你不想这样做,因为长期交易,特别是在交互式环境中,只是简单的坏.就像“穿越溪流”一样糟糕.不要这样做.批处理事务是不同的,但交互式长期事务是错误的.
您希望将交互式事务保持为实际的短暂状态.
现在,如果您无法确保您能够为您的交易使用相同的数据库连接,恭喜您,您可以实现自己的交易.这意味着您可以设计系统和数据流,就好像后端没有事务处理功能一样.
这实际上意味着您需要提出自己的机制来“提交”您的数据.
执行此操作的一种好方法是将数据逐步构建到单个“事务”文档中,然后将该文档提供给执行大部分实际工作的“保存”例程.比如,您可以在数据库中存储一行,并将其标记为“未保存”.您可以对所有行执行此操作,最后调用运行您刚刚存储的所有数据的例程,并将其全部标记为在单个事务小批处理过程中“保存”.
同时,所有其他sql“忽略”未“保存”的数据.抛出一些时间戳,并有一个收割机进程清理(如果你真的想要打扰 – 实际上可能更容易在数据库中留下死行,取决于数量),这些死的“未保存”行,因为这些是“未经注册”的交易.
它没有听起来那么糟糕.如果你真的想要一个无状态的环境,这对我来说就是这样,那么你需要做这样的事情.
记住,在所有这些中,持久性技术实际上与它无关.问题是你如何使用你的交易,而不是技术.
