EJB 事务与 Oracle 事务
我在这里有一个奇迹。 我有一个带有 EJB 的 Web 应用程序来与数据库进行通信。 我打算在两个不同的应用程序服务器上运行它（在不同的硬件和所有设备上运行的完全不同的服务器）。 我打算让他们共享一个数据库。
它如何与交易配合使用？我有两台独立的服务器（即两个独立的 EJB 事务存储库）和只有一个数据库（即一个数据库事务“存储库”），这是否存在风险？
这安全吗？
我确实知道该架构无效，并且有更好的方法，但是关于 EJB 与 Oracle 事务，我的立场是什么？
谢谢。
I have a wonder here.
I have a web application with EJBs to communicate with database.
I intend to run it on two distinct application servers (completely distinct servers running on different hardware and everything).
I intend to have them share one single database.
How does it work with transactions? is it a risk that I have two separate servers so two separate EJB transaction repositories and only one database, so one "repository" of database transactions?
Is this safe?
I do know the architecture is not valid, and that there are better ways, but about this EJB vs Oracle transaction, where di I stand?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
JTA 发生相反的情况，我的意思是，当您从 1 个 EJB 上下文与多个事务资源（例如，2 个不同的数据库或 JMS 服务器或其他）交互时。这不是你的情况。当 EJB 事务启动时，JTA 会小心地在这些资源的每一个中启动 1 个事务，并与 EJB 事务一起提交所有这些资源（如果其中一个失败则回滚所有资源）。
在您的情况下，您可以使用 JTA，也可以不使用，因为您只有 1 个事务资源。
回答您的问题，您可以安全地从不同的 EJB 应用程序访问同一个数据库，没有风险，因为数据的完整性将由数据库的事务引擎保证。
当您从 EJB 上下文与 EntityManager（它又与数据库通信）进行通信时，数据库事务会自动启动，该事务与数据库中启动的其他事务隔离（例如，与其他 EJB 上下文（您的情况）或任何其他应用）。
我希望它有帮助。
JTA takes place the opposite scenario, I mean, when from 1 EJB context you are interacting with several transactional resources (for example, 2 different databases, or JMS servers, or others). This is not your case. JTA takes care to initiate 1 transaction in each one of these resources when a EJB transaction starts, and commit in all of them (or rollback all of them if one fails) along with the EJB transaction.
In your case you can use JTA or not because you have only 1 transactional resource.
Answering your question, you can safely access from different EJB applications to the same database without risk, because the integrity of the data is going to be guarranteed by the transactional engine of the database.
When you communicate from an EJB context with, lets say, an EntityManager (that in turn communicates with a database) a Database transaction is automatically started, that is isolated from other transactions started in the Database (for example, from other EJB contexts (your case) or whaterver other application).
I hope it helps.
您没有说明一台服务器上是否有 EJB 对第二台服务器上的其他 EJB 进行远程调用。
如果我们假设您只是将应用程序部署到具有两个节点的集群应用程序服务器，则 XA（两阶段提交）不相关，因为您可以使您的应用程序使用本地 EJB，这意味着 EJB 之间的所有通信都保留在一个节点上节点。
您需要在两个节点前面放置一个负载均衡器，它可以在两个节点之间分担负载。
这样做意味着来自客户端浏览器的任何单个请求都完全在一个节点内处理，这将提供良好的性能，因为 EJB 之间没有远程调用。因此，来自 Web 层的单个请求将在进入 EJB 容器时启动一个事务（如果需要），并且该事务将在 EJB 调用返回时提交（除非 EJB 容器确定由于异常或异常而需要回滚）显式调用上下文来回滚事务）。
像这样的简单架构是很正常的，您会发现世界各地有数千个应用程序都是这样构建的。
随着您的 Web 应用程序负载随着用户数量的增加而增加，您可以通过添加越来越多的节点来进行扩展 - 应用程序服务器管理器将确保应用程序部署到新节点。
这种架构的唯一问题是当节点“消失”时会发生什么，例如由于崩溃或因硬件维护而被关闭。在这种情况下，用户的 Web 会话将会丢失，除非您已告诉应用程序服务器跨节点共享会话。如果这样做，整体性能会受到影响，因为节点之间会不断共享会话状态。或者，如果未激活此功能，则会遇到负载均衡器需要将连续的 Web 请求路由到同一节点的问题。
您将最了解您的需求，并且必须准确选择您选择的架构。
You don't say if you have EJBs on one server making remote calls to other EJBs on the second server.
If we assume you are simply going to deploy your application to a clustered App Server with two nodes, then XA (two phase commit) isn't relevant, because you can make your app use local EJBs meaning that all communication between EJBs stays on one node.
You need to stick a load balancer infront of the two nodes and it can share the load between the two nodes.
Doing it this way will mean that any single request from a client browser is entirely handled within one node, which will give good performance because you have no remote calls between EJBs. As such, a single request from the web tier will start a transaction as it enters the EJB container (if required) and that transaction will be committed when the EJB call returns (unless the EJB container determines it needs to rollback due to an exception or explicit call to the context to roll the transaction back).
A simple architecture like this is quite normal and you will find thousands of apps around the world built like this.
As your webapp load increases with more users, you can scale out by adding more and more nodes - the app server manager will ensure that the app is deployed to the new nodes.
The only issue with this architecture is the question of what happens when a node "disappears", say due to a crash or if its taken down for say hardware maintenance. In this case, a user's web session will be lost, unless you have told the app server to share sessions across nodes. If you do this, overall performance suffers, because of the continual sharing of session state between nodes. Alternatively, if this feature isn't activated, you have the problem that successive web requests need to be routed to the same node by the load balancer.
You will know your requirements best and have to choose exactly which architecture you choose.
其工作方式是通过 JTA。
JTA 支持分布式事务及其管理。要使数据库能够参与分布式事务，您必须使用 XA（事务感知）资源。
这是一篇关于 EJB3 和事务的文章。它有点过时，但它解决了详细信息
http://java.sys-con.com/node /325149
就像其他一切一样，使用 JTA 和 XA 也有风险和好处。您可以保证数据完整性，并且如果您的应用程序严重依赖于事务性，那么这可能是一种值得的方法。这样做的缺点是 XA 性能较差，并且始终存在某些 dosnwstream 应用程序可能最终长时间持有数据库锁的风险。
The way this works is through JTA.
JTA supports distributed transactions and their management. To enable a database to participate in a distributed transaction, you have to use XA (transaction aware ) resources.
Here is an article about EJB3 and transactions. Its a bit dated, but it addresses the details
http://java.sys-con.com/node/325149
Just like everything else, there are risks and benefits from using JTA and XA. You are guaranteed data integrity and if your application relies heavily on being transactional, then this might be a worthwhile approach. The downside of this is that XA is less-performant and there is always the risk that some dosnwstream application might end up holding a database lock for a very long time.