有没有办法在多个客户端和服务器提交后显式提交和回滚事务
环境：该应用程序使用 Spring Framework 2.5.6.SEC01 和 iBatis 2.3.4.726。这就是MVC设计。
场景如下：
从客户端输入/更新数据
按更新按钮提交
处理数据并执行DML（插入、更新、删除）
返回结果给客户端并显示数据
但是，在加载页面后，我需要通过Javascript调用API（我无法控制API，只需要传递所需的参数并检查结果是否成功或错误）
如果 API 返回 SUCCESS，则无需执行任何操作。但它返回 ERROR，我给出警报消息以通知用户。
我有视图（客户端）、服务和数据访问层。当客户端进行提交（场景#2）时，它进入服务处理数据并自动启动事务（场景#3）。退出服务并返回客户端时自动执行提交以显示数据（场景#4）。
问题：如何挂起事务而不执行提交，然后返回客户端通过Javascript调用API。 当 API 返回 SUCCESS 时，通过 Ajax（或其他方式）执行提交，或者另一方面，回滚它。
任何有关正确方向的指导都值得赞赏。
Environment: The application is using Spring Framework 2.5.6.SEC01 and iBatis 2.3.4.726. It is MVC design.
Here's the scenario:
Input/update data from the client
Press Update button to submit
Process the data and execute DML (insert, update, delete)
Back the result to client and display the data
However, upon the page loaded, I need to call the API via Javascript (i have no control with the API, just need to pass the required parameter and check the result if SUCCESS or ERROR)
If API returns SUCCESS, nothing to do. But it returns ERROR, I give alert message to inform the user.
I have View(client), Service and Data Access Layers. When the client do the submit (scenario #2), it enters the Service to process the data and automatically start Transaction (scenario #3). Automatically execute the commit upon exit to Service and back to client to show the data (scenario #4).
Problem: How can I suspend the transaction not to execute the commit, then back to client to call API via Javascript. When API returns SUCCESS, execute commit via Ajax (or other way) or in the other hand, rollback it.
Any guidance on the right direction is appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果我理解正确的话，您想要启动一个数据库事务，插入数据（不提交），保持连接和事务打开，返回到客户端，并根据一些 javascript 结果，进行提交。
这感觉像是一个奇怪的设计，客户端实际上可以保持连接打开，使您的应用程序极易受到 (D)DOS 攻击或一般客户端问题。
我会非常努力地对其进行如下改造：
这更快、更健壮，而且代码也可能更少。
If I understand correctly, you want to start a database transaction, insert data (without comitting), keeping the connection and the transaction open, return to the client, and based on some javascript result, do a commit.
This feels like a strange design where the client can actually keep a connection open, making your application extremely vulnerable for (D)DOS attacks or client problems in general.
I would try really hard to remodel it as follows:
This is quicker, more robust and also probably less code.