当我们已经有在线订购交易时，我们还需要记录级别锁定吗？ （演唱会门票或机票预订）
对于在线订购音乐会座位或机票，我们是否需要记录级别锁定或交易是否足够好？
对于演唱会门票（比如20B号座位），或者机票（即使超额预订，限制也是210张），我认为网站在显示购票屏幕时无法锁定任何记录或开始交易。
但是当用户点击“确认购买”后，服务器应该开始一个交易，购买席位号20B，并尝试Commit。
如果另一个用户在之前的交易中已经购买了Seat 20B，那么当前交易会失败的是“Commit”部分吗？
那么...我们不需要记录级锁定？事务是否总是序列化（一个接一个），这就是为什么我们可以确定不存在“竞争条件”？那么什么情况下需要记录级锁定呢？
For online ordering of concert seats or airline tickets, do we need Record Level Locking or is Transaction good enough?
For concert ticket (say, seat Number 20B), or airline ticket (even with overbooking, the limit is 210, for example), I think the website cannot lock any record or begin transaction when showing the ticket purchase screen.
But after the user clicks "Confirm Purchase", then the server should Begin a Transaction, Purchase Seat Number 20B, and try to Commit.
If another user already bought Seat 20B in a previous transaction, then it is the "Commit" part that the current transaction will fail?
So... we don't need Record Level Locking? Do Transactions always go serialized (one after another), so that's why we can know for sure there is no "race condition"? In what situation is Record Level Locking needed then?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在插入行之前，您可以检查具有相同 SeatId 的条目存在的位置。如果存在则回滚，否则插入行并提交。我什至不自信，我认为如果服务非常繁忙，您可能需要在开始插入操作之前锁定。
然而还有一个令人兴奋的第二种选择。
您维护
showId和seatId用这两个做一个索引。并在此索引上创建唯一的约束。
现在开始使用任何锁定的事务。
如果存在重复。由于独特的约束，它显然会失败。并且提交将会失败。
尼尔
Before Inserting the Row You might Check where entries with same SeatId exists. If exists roll it back otherwise Insert the Row and Commit. I am not even Cofident and I think If the service is quite busy you probabbly need locking before starting the insert operation.
However There Is a Exciting Second Option.
You maintain a
showIdandseatIdmake an index with this two. and create an unique Constraint on this Index.
Now Start the Transaction with any locking.
if duplication exists. it will obviously fail due to unique constraint. and commit will be unsuccessful.
Neel