111,126
社区成员
发帖
与我相关
我的任务
分享throw new ........这样的代码,这就会造成回滚。但是如果你的业务逻辑就有”放弃“的流程,那么你就没有必要用什么 throw 了,直接应该写 rollback了。
另外,在更宽的设计范围内,”放弃“动作并不是 rollback。例如一个人购买一张机票,在付款之前他放弃了,那么这张机票就会重新回到”可销售的机票“池中,也就是说所谓”放弃“是一系列业务操作,而不是什么数据库回滚操作。在这类业务程序设计中,如果你只是用数据库事务的概念来理解”放弃“,那么你可能造成很多尴尬的结果。例如一个人迟迟不付款,例如操作员去上厕所了,那么是不是上万、数十万的售票点的电脑都要死锁去等待它一个售票点commit或者rollback呢?
只是用数据库的概念来生搬硬套到业务流程处理上,是很扯的,会造成完全不在同一个设计频道上的情况。只有你详细研究了业务操作流程图,知道哪些是瞬间的技术事务操作,哪些是长时间的业务事务操作,你才能判断这是一个技术问题还是业务问题。只有很低级的技术问题,才用数据库的技术观念去考虑。
我感觉楼主有点钻入牛角尖。
1. 我觉得没有用到的时候可以了解这个东西的用法,但是没必要纠结什么时候可以用到(个人而言,遇到适用情况就才会想到还有这东西可用)。
2. 因为BeginTran跟Commit之间还有很多逻辑,有时候掺杂一些业务逻辑或者互斥逻辑的时候,不就可以手动调用RollBack来回滚这些修改吗?给开发者提供更自由的发挥空间。(所以上面说楼主有点钻牛角尖)
例如业务要求Update一条语句失败的时候(返回0行被修改)就要提示用户是否继续,当用户点击取消的时候要取消本次修改。这个时候如果没有RollBack方法,那你就哭吧。