我在这里有一个奇迹。 我有一个带有EJB的Web应用程序来与数据库进行通信。 我打算在两个不同的应用服务器上运行它(完全不同的服务器在不同的硬件和所有东西上运行)。 我打算让他们共享一个数据库。
它如何与交易一起使用?是否存在风险,我有两个独立的服务器,因此有两个独立的EJB事务存储库和一个数据库,因此数据库事务的一个“存储库”?
这样安全吗?
我确实知道架构是无效的,并且有更好的方法,但关于这个EJB与Oracle的交易,我站在哪里?
谢谢。
答案 0 :(得分:4)
JTA发生了相反的情况,我的意思是,当您从1个EJB上下文与几个事务资源(例如,2个不同的数据库,或JMS服务器或其他)进行交互时。这不是你的情况。当EJB事务启动时,JTA负责在每个资源中启动1个事务,并在所有这些资源中提交(或者如果一个失败则回滚所有这些事务)以及EJB事务。
在您的情况下,您可以使用JTA,因为您只有1个交易资源。
回答你的问题,你可以安全地从不同的EJB应用程序访问同一个数据库而没有风险,因为数据的事务引擎将保证数据的完整性。
当您从EJB上下文与EntityManager(后者又与数据库通信)进行通信时,会自动启动数据库事务,该事务与在数据库中启动的其他事务隔离(例如,从其他EJB中隔离)上下文(您的情况)或其他应用程序。)
我希望它有所帮助。
答案 1 :(得分:2)
您没有说在一台服务器上是否有EJB对第二台服务器上的其他EJB进行远程调用。
如果我们假设您只是将应用程序部署到具有两个节点的集群App Server,则XA(两阶段提交)不相关,因为您可以使您的应用程序使用本地EJB,这意味着EJB之间的所有通信留在一个节点上。
您需要在两个节点前面放置一个负载均衡器,它可以共享两个节点之间的负载。
这样做意味着来自客户端浏览器的任何单个请求都完全在一个节点内处理,这将提供良好的性能,因为EJB之间没有远程调用。因此,来自Web层的单个请求将在进入EJB容器(如果需要)时启动事务,并且该事务将在EJB调用返回时提交(除非EJB容器确定它需要由于异常或显式调用上下文以回滚事务。)
像这样的简单架构是很正常的,你会发现全世界成千上万的应用程序都是这样构建的。
随着您的webapp负载随着更多用户的增加而增加,您可以通过添加越来越多的节点来扩展 - 应用服务器管理器将确保将应用程序部署到新节点。
此架构的唯一问题是当节点“消失”时会发生什么,例如由于崩溃或者因为硬件维护而被取消。在这种情况下,除非您已告知应用服务器跨节点共享会话,否则用户的Web会话将丢失。如果这样做,整体性能会受到影响,因为节点之间会话状态的持续共享。或者,如果未激活此功能,则会遇到负载均衡器需要将连续的Web请求路由到同一节点的问题。
您将最了解您的要求,并且必须准确选择您选择的架构。
答案 2 :(得分:1)
这种方式的工作方式是通过JTA。
JTA支持分布式事务及其管理。要使数据库能够参与分布式事务,您必须使用XA(事务感知)资源。
这是一篇关于EJB3和事务的文章。它有点陈旧,但它解决了细节
http://java.sys-con.com/node/325149
就像其他一切一样,使用JTA和XA也存在风险和好处。保证数据完整性,如果您的应用程序严重依赖于事务性,那么这可能是一种有价值的方法。这样做的缺点是XA的性能较差,并且总有一些dosnwstream应用程序可能会在很长一段时间内持有数据库锁的风险。