1、如果仅仅考虑技术问题，那么肯定会得出最坏的解答，因为技术是没有智能的、最笨的东西，只有先用智能后用技术才能解决问题。
“查询-订票-收款-出票”是一个事务不假，但是它并不是一个1、2秒钟的数据库操作事务，而是一个持续较长时间（例如超过10秒钟）的业务。试想一下，如果一个终端在处理一张车票的时候所有其它几百的终端都被阻塞——“死机”——在这里了，或者幻读、赃读的终端每处理10次票仅能成功1次，而其它9次都会在操作员操作最后一步才出现提示“记录已经被修改，您的操作被回滚放弃，请重新执行订票流程”，这是多么让人懊恼的恶劣设计呀！
其实流程很简单，就是在订票开始就将票从“无人订购”表移到一个“正在处理”的表中。订票点的操作，收款、出票等，都是针对“正在处理”表中具体的票资源的操作，并不去动别人正在处理的票。订票点可以放弃处理从而把票放回“无人订购”的表中，也有可能后台会在超时（例如2分钟）之后自动处理这个。
事务锁不是一个业务处理的概念，而是一个处理软件编码的后期细节的技术。如果大家都把高级的业务流程当成低级的计算机技术来看待，会给用户带来无尽的烦恼，会产生大量成事不足的“错误地技术化了”的解决方案。
提供的解决办法还有一点问题，将“无人订购”表移到“正在处理”的表时机如何掌握。如果是查询时移动，到底要移走多少张票（我们买票时都是先只告知车次，售票点查询之后再问我们要几张票），如果全数移入“正在处理”的表，那此时别的地方查询时就只能显示车次的票售完；如果是先查询，在出票时才移动，票可能已经被别的地方售出了，购买会失败。
2、DbCommandBuilder中
public enum ConflictOption
该枚举
CompareRowVersion
如果表中存在任何 Timestamp 列，则这些列在 WHERE 子句中用于所有生成的更新语句。这等效于指定 CompareRowVersionUpdate | CompareRowVersionDelete。
net2.0中使用DbDataAdapter更新数据库。套用DbCommandBuilder自动生成的sql语句，where部分卡的很严格的，基本字段都要在where后面卡一下。如果有高精度的字段存在，可以防止并发。
3、事实上火车票的售票系统肯定是不会简单的用事务来避免并发的。
可以为每一个售票窗口预留一些车票，如10张，售一张就请求一张未售的票加入预留队列，但未售的车票达到某个临界值时，如20张，就开始按照各个售票窗口的出货情况和缺货情况来分配
