当前位置:  开发笔记 > 编程语言 > 正文

Hibernate或TopLink的替代品?

如何解决《Hibernate或TopLink的替代品?》经验,为你挑选了2个好方法。

有没有可行的Hibernate替代品?优选不以JPA为基础的东西.

我们的问题是我们正在构建一个复杂的(如同许多对象相互引用)有状态的RIA系统.似乎Hibernate主要用于一次性应用程序 - JSF等.

问题主要是延迟加载.由于在初始化和实际加载惰性集合之间可能存在多个HTTP请求,因此每个事务的会话都是不可能的.一个长期存在的会话(每个应用程序一个)也不能正常工作,因为一旦事务遇到障碍并抛出异常,整个会话就会失效,因此延迟加载的对象会中断.然后有各种各样的东西对我们不起作用(比如隐藏数据持久化来自初始化事务之外的数据).

除了我可怜的解释,最重要的是Hibernate做了我们不喜欢的魔术.看起来TopLink并没有更好,它也是在EJB之上编写的.

因此,无状态持久层(甚至是足够明亮的面向对象的数据库抽象层)是我们最需要的.

有什么想法,还是我要求不存在的东西?

编辑:我很抱歉我的模糊术语,并感谢大家的更正和有见地的答案.那些纠正我的人,你们都是正确的,我的意思是JPA,而不是EJB.



1> cletus..:

如果您正在追踪另一个JPA提供程序(Hibernate就是其中之一),那么请查看EclipseLink.它比TopLink Essentials的JPA 1.0参考实现功能更全面.实际上,EclipseLink将是Glassfish V3 Final附带的JPA 2.0参考实现.

JPA很好,因为你可以在容器内外使用它.我写过使用JPA的Swing客户端效果很好.它没有EJB 2.0/2.1附带的相同耻辱和XML包袱.

如果您正在使用更轻量级的解决方案,那么我认为ibatis是Java平台的首选持久性技术.它是轻量级的,依赖于SQL(令人惊讶的是,ORM用户花了多少时间来尝试使他们的ORM产生良好的SQL)并且做了JPA所做的90-95%(如果你愿意,还包括延迟加载相关实体).

只是为了纠正几点:

JPA是EJB的持久层,不是基于EJB构建的;

任何体面的JPA提供商都会进行大量的缓存,而且很难全部解决(这将是"为什么简单性如此复杂?")的一个很好的例子.除非您正在做一些您没有指出的事情,否则异常不应成为您的托管对象的问题.运行时异常通常是回滚事务(如果使用Spring的事务管理而谁不这样做?).提供程序将维护已加载或持久对象的缓存副本.如果要在实体管理器外部进行更新(需要显式缓存刷新或使用EntityManager.refresh()),这可能会有问题.



2> Will Hartung..:

如前所述,JPA <> EJB,它们甚至都不相关.EJB 3恰好利用JPA,但就是这样.我们有很多使用JP​​A的东西甚至没有接近运行EJB.

你的问题不是技术,而是你的设计.

或者,我应该说,你的设计并不适合任何现代框架.

具体来说,您尝试通过多个HTTP请求保持事务处于活动状态.

当然,大多数常见的习惯用法是每个请求本身就是一个或多个事务,而不是每个请求都是更大事务的一部分.

当您在同一讨论中使用术语"无状态"和"事务"时,也存在明显的混淆,因为事务本质上是有状态的.

您的大问题是手动管理您的交易.

如果您的事务发生在多个HTTP请求上,并且这些HTTP请求碰巧正在"非常快"地运行,那么您应该不会真正遇到任何实际问题,除非您必须确保您的HTTP请求使用相同的数据库连接以利用数据库事务工具.

也就是说,简单来说,您可以获得与数据库的连接,将其填充到会话中,并确保在事务持续期间,您的所有HTTP请求不仅通过相同的会话,而且通过这种方式实际连接仍然有效.具体来说,我不相信有一个现成的JDBC连接,它实际上可以在故障转移或从一台机器到另一台机器的负载平衡中存活.

因此,简单地说,如果要使用数据库事务,则需要确保使用相同的数据库连接.

现在,如果您的长期运行事务中包含"用户交互",即您启动数据库事务并等待用户"做某事",那么,很简单,该设计完全错误.你不想这样做,因为长期交易,特别是在交互式环境中,只是简单的坏.就像"穿越溪流"一样糟糕.不要这样做.批处理事务是不同的,但交互式长期事务是错误的.

您希望将交互式事务保持为实际的短暂状态.

现在,如果您无法确保您能够为您的交易使用相同的数据库连接,那么,恭喜您,您可以实现自己的交易.这意味着您可以设计系统和数据流,就好像后端没有事务处理功能一样.

这实际上意味着您需要提出自己的机制来"提交"您的数据.

执行此操作的一种好方法是将数据逐步构建到单个"事务"文档中,然后将该文档提供给执行大部分实际工作的"保存"例程.比如,您可以在数据库中存储一行,并将其标记为"未保存".您可以对所有行执行此操作,最后调用运行您刚刚存储的所有数据的例程,并将其全部标记为在单个事务小批处理过程中"保存".

同时,所有其他SQL"忽略"未"保存"的数据.抛出一些时间戳,并有一个收割机进程清理(如果你真的想要打扰 - 实际上可能更容易在数据库中留下死行,取决于数量),这些死的"未保存"行,因为这些是"未经注册"的交易.

它没有听起来那么糟糕.如果你真的想要一个无状态的环境,这对我来说就是这样,那么你需要做这样的事情.

记住,在所有这些中,持久性技术实际上与它无关.问题是你如何使用你的交易,而不是技术.

推荐阅读
135369一生真爱_890
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有