这样的设计在高并发环境下性能如何

你这样利用事务+SQL肯定是不行的，性能慢。建议对内存中对象操作，并发使用高性能锁来控制，现在JDK5/6中都有很好的控制。

听起来是个全新的概念

我这样理解你的话不知道对不？
把item的数量加载到内存中去。使用concurrent包中提供的atom类
当其买主如果要执行购买操作之前，必须获得item的数量上的锁

你这个业务有些排队性质，先来后到买最后一件，也有另外一个方案，使用线程Queue或JMS来实现，第一个请求先进入Queue，首先得到资源。

并发同步情况下使用线程锁，就没有严格的先来后到，当然也要考虑公平锁和非公平锁的问题，尽量让先发出请求的线程锁住资源，但最终是由CPU来控制的，或者使用Future.get和Callable这样新的并发API来解决。

无论什么样的方式对多消费者单一资源的情况只能是通过将消费者请求串行化的方式解决，为了完成可用资源计数，当第一个消费者完成了消费过程的时候才允许第二个消费者获取资源。但是在实现上可从2个角度着手：控制消费者的申请、控制资源的发放

针对于商品与买家的关系可以有以下的一些方法实现：
1.对可用资源建立一个队列将所有的申购排队，按照先后顺序逐一提交，只有当前一个人申购失败之后才允许下一个申购。在你的业务过程中这个排队也许是长期的，就像论坛里买东西的申购排队一样（常见“排队”等的回帖），第二个人的申购请求可能是在好多天之后才开始进入处理过程的，而他之后还有好几个人在等待呢。这里涉及到了持久化消费者session的过程，实现难度可能会比较大。

2.对可用资源建立一个队列将所有的申购排队，第一个入队的可以提交申请，当队列发现剩余资源不足的时候剩下的所有请求都会被拒绝掉，被拒绝的人可以再次提出申购请求，同时对于该资源不再保留消费者队列。直到检查发现资源再次可用的时候，才开启此资源的申购队列。相比较与上一种方案此时不需要考虑申购者的session维护，实现难度下降很多了。

前2中方案实际上是在控制申购者的操作能否发生。

3.消费者乱序竞争先到者将资源锁定，完成消费过程后解锁此后开始下一轮的竞争。此时同样需要考虑等待被锁定资源的申购者session是否需要持久化。

此种方案实际上是在控制资源，使它保持独占使用。

无论是哪一种方式都已经不是在考虑“数据”，无论资源还是消费者都是脱离数据的对象。对于“2”这个数字的锁定是没有意义的，对于“xx显示器”这个资源的锁定是可以被理解的，对于消费者也是同理。