spring-management-transaction 可以在多个 request-response-s 中生存吗?

发布于 2024-11-14 12:51:55 字数 640 浏览 2 评论 0原文

我目前正在使用 jsf 2、jpa 2 和 spring 3 进行开发。

我想我非常了解 @Transactional 的使用及其传播,但是,这仅适用于一个线程,在我的情况下,这是我的 web 应用程序的一个请求

响应我需要的是:

  1. 远程业务服务的客户端是启动和结束事务的客户端
  2. 如果发生任何异常,弹簧将进行异常转换

这是一个希望可以描述意图的示例:

  1. 客户端(假设它是移动设备,不一定是 webapp)要求服务器创建一个新事务
  2. 服务器返回一个事务 id
  3. 客户端调用 serviceA,传递 transactionId 来使用
  4. serviceA 使用事务运行(基于传递的 transactionId)完成,但是事务未提交
  5. 客户端继续调用serviceB,传递相同的transactionId来使用
  6. serviceB,如果serviceB运行正常,则使用serviceA发起的上一个事务来运行serviceB
  7. ,那么客户端可以根据transactionId要求服务器提交,
  8. 如果serviceB运行异常,spring然后可以做sql异常翻译

这可能吗?

谢谢 !

im currently developing using jsf 2, jpa 2, and spring 3.

I think i quite understand the use of @Transactional and it's propagation, but stil, that only applies to one thread, which in my case is one request response of my webapp

Basically what i need is :

  1. the client of the remote business service is the one that initiates and ends the transaction
  2. spring wil do the exception translation if any exception occurs

Here's an example that hopefully can describe the intention :

  1. the client(assuming it's a mobile device, not necessarily a webapp) ask the server to create a new transaction
  2. the server returns a transaction id
  3. the client calls serviceA, passing the transactionId to use
  4. the serviceA runs using the transaction (based on the transactionId passed) finishes, but the transaction is not commited
  5. the client continues calling serviceB, passing the same transactionId to use
  6. serviceB runs using the previous transaction initiated by serviceA
  7. if serviceB runs correctly, then the client can ask the server to commit based on the transactionId
  8. if serviceB runs with exception, spring could then do the sql exception translation

Is this possible ?

Thank you !

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

怪我鬧 2024-11-21 12:51:55

我希望你实际上不需要这么长的交易...这通常是一个坏主意,因为交易应该尽可能短(只是google 这个咒语(如果您对此有疑问)以获取解释)。

相反,您可能只需要“长时间对话”:基本上,您在多个调用/请求中使用分离的实体(对数据库进行只读访问),然后当您“准备好提交您的交易。

无论哪种方式,@Transactional 在这里确实没有用,我不知道有任何开箱即用的机制可以实现您所描述的功能。

也许考虑使用 spring webflow:它提供了易于使用的对话相关功能,并且应该在您的上下文中运行良好(JPA/JSF)...

请参阅相关讨论 此处

华泰

I hope you actually don't need such a long transaction... It usually is quite a bad idea, since transactions should be as short as possible (just google this mantra for explanations if you doubt it).

Instead, it may be possible that you just need "long conversations": basically, you work with detached entities across multiple calls/requests (making read-only accesses to your database), then you reattach them (with your changes) when you're ready to commit your tx.

Either way, @Transactional is indeed of no use here and I'm not aware of any out-of-the-box mechanism achieving what you describe.

Maybe consider using spring webflow: it provides easy-to-use conversation-related features and should work very well in your context (JPA/JSF)...

See related discussion here.

HTH

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文