将请求无缝包装到 (JTA) 事务中
根据我的理解，Seam将每个请求包装成一个Transaction。我的Web应用程序（编码到一些seam有状态bean中）目前正在调用一些EJB接口，该接口是应用程序服务器的一部分，它还为桌面客户端提供服务（一个完整的服务器应用程序，提供我的Web应用程序所需的所有功能）。
现在，从 Seam bean 到这些 ejb 方法的后续调用被 Seam 容器包装到它自己的事务中，谢谢，但是中间没有发生“刷新”，这意味着实体管理器不会向我返回有关 ejb 的最新数据。随后的电话。
我通过简单地在 ejb 类中添加一些方法来解决这个问题，这些方法本身会创建一个新的事务（在执行结束时强制“刷新”）。如果一步出错，我很高兴不会回滚所有内容。 我在任何地方都找不到如何配置 Seam 将每个 ejb 调用的执行包装到一个事务中，而不是包装整个请求执行。
有什么想法吗？
According to my understanding, Seam wraps each request into a Transaction. My web app (code into some seam stateful beans) is at the moment calling some EJB interface which is part of an application server, which also serves a desktop client (an whole complete server application providing all features I need for my web app).
Now, making subsequent calls from seam beans to those ejb methods is wrapped into its own transaction by the Seam container, thanks, but no 'flush' in between is happening, meaning the entity manager does not return to me up to date data on the subsequent calls.
I worked around that by simply adding some methods into the ejb classes which themselves create a new Transaction (forcing the 'flush' at the end of their execution). I'm happy with NOT rolling back everything if on step went wrong.
I can't find anywhere how to maybe configure Seam to wrap the execution of EACH ejb calls into a transaction instead of wrapping the WHOLE request execution.
Any idea ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，Seam 将每个请求包装成两个 事务（用于 JSF 渲染响应的额外只读事务）。您可以通过禁用来禁用此行为 Seam 的事务管理，但这将为所有类型的延迟初始化异常打开大门...
在我遇到此问题的（罕见）情况下，我通常在 EntityManager 上执行手动刷新/刷新。然而，在大多数情况下，通过不同方法操作的数据应按其性质分开
Well, Seam wraps each requests into two transactions (an extra read-only transaction for JSF render response). You can disable this behavior by disabling Seam's transactions management, but this would open the gate for all kind of lazy initialization exceptions...
In the (rare) cases when this problem occurred to me, I usually executed a manual flush / refresh on the EntityManager. In most cases the data manipulated by different methods should be separated by it's nature, however