案例一:订票系统案例，某航班只有一张机票，假定有1w个人打开你的网站来订票，问你如何解决并发问题(可扩展到任何高并发网站要考虑
的并发读写问题)
问题，1w个人来访问，票没出去前要保证大家都能看到有票，不可能一个人在看到票的时候别人就不能看了。到底谁能抢到，那得看这个人的“运气”（网
络快慢等）
其次考虑的问题，并发，1w个人同时点击购买，到底谁能成交？总共只有一张票。
首先我们容易想到和并发相关的几个方案 ：
锁同步同步更多指的是应用程序的层面，多个线程进来，只能一个一个的访问，java中指的是syncrinized关键字。锁也有2个层面，一个是java中谈到的对
象锁，用于线程同步；另外一个层面是数据库的锁；如果是分布式的系统，显然只能利用数据库端的锁来实现。
假定我们采用了同步机制或者数据库物理锁机制，如何保证1w个人还能同时看到有票，显然会牺牲性能，在高并发网站中是不可取的。使用hibernate后我们
提出了另外一个概念：乐观锁、悲观锁（即传统的物理锁）；
采用乐观锁即可解决此问题。乐观锁意思是不锁定表的情况下，利用业务的控制来解决并发问题，这样即保证数据的并发可读性又保证保存数据的排他性，保证性能的同时解决了并发带来的脏数据问题。
hibernate中如何实现乐观锁：
前提：在现有表当中增加一个冗余字段，version版本号, long类型
原理：
1）只有当前版本号》=数据库表版本号，才能提交
2）提交成功后，版本号version ++
实现很简单：在ormapping增加一属性optimistic-lock="version"即可，以下是样例片段
optimistic-lock="version"table="T_Stock" schema="STOCK">
