控制器连接终止后(即客户端超时)事务回滚

发布于 2024-12-03 20:52:18 字数 558 浏览 1 评论 0原文

想象一下场景; 我有一个移动应用程序,它从 Spring 管理的服务器中提取 20 美元,并等待确认,然后在应用程序上将其标记为完成。

然而;

  1. 移动应用程序将提款请求发送到服务器

  2. 控制器接收请求并调用服务器层服务层如何花费异常长的时间来提款钱(原因不重要)。

  3. 移动应用程序超时(带有 SocketException),并且请求将重新排队,直到它可以再次与应用程序通信。

  4. 服务器完成了从1开始的请求,但不知道客户端已超时。

我们现在的场景是,移动应用程序认为 20 美元失败,但服务器执行了请求。

所以问题;

• 当套接字关闭时(即当移动应用程序超时请求时),Spring 事务是否可以回滚?

• 如果不是——实现上述目标的最佳方法是什么?

服务器上的一些信息 • 春季3.1 • 基于Spring 的控制器/服务/DAO。 • 休眠 (JPA) • MYSQL 数据存储

谢谢,

Ian。

Picture the scene;
I have a mobile App that withdraws $20 from a Spring managed Server and waits for confirmation before marking it complete on the app.

However;

  1. Mobile app sends the withdraw request to the server

  2. Controller receives the request and calls the server tier how service tier takes an un-usually long time to withdraw the money (reason not important ).

  3. Mobile App times out (with a SocketException) and the request is re-queued until it can speak to the application again.

  4. The Server completes the request from 1 but does not know the client has timed out.

We now have the scenario in that the mobile application believes the 20 dollars failed but the server carried out the request.

So the questions;

• Can Spring transactions Rollback when sockets are closed (i.e. when the mobile application times out the request)?

• If not – what is the best approach to achieve the above?

Some info on the server
• Spring 3.1
• Spring based controllers/services/DAO's.
• Hibernate (JPA)
• MYSQL Data store

Thanks,

Ian.

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

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

发布评论

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

评论(1

悲喜皆因你 2024-12-10 20:52:18

当套接字关闭时(即移动应用程序超时请求时),Spring 事务是否可以回滚?

目前我无法想象这会如何运作......

如果不是——实现上述目标的最佳方法是什么?

我会这样处理问题:

  • 移动应用程序发送某种令牌/uuid,用于
  • 在请求超时时识别提款,移动应用程序在内部将提款标记为某种“未知结果”状态,而不是重新安排,移动应用程序可以使用令牌向服务器询问状态
  • “未知结果”应该仅在一段时间内有效(例如5分钟),否则假设提款不起作用并重新安排
  • 服务器上的交易也应该有超时(并满足时间“未知的结果”)

希望有帮助。

Can Spring transactions Rollback when sockets are closed (i.e. when the mobile application times out the request)?

At the moment I can't imagine how that might work ...

If not – what is the best approach to achieve the above?

I would deal with the problem like this:

  • the mobile app sends some kind of token / uuid that identifies the withdrawal
  • if the request times out, the mobile app marks the withdrawal internally as some kind of "unknown outcome" state and instead of rescheduling, the mobile app can ask the server about the state using the token
  • the "unknown outcome" should only be valid for some time (e.g. 5 minutes) otherwise assume the withdrawal didn't work and reschedule
  • the transaction on the server should have a timeout too (and meet the time of the "unknown outcome")

Hope that helps.

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