题外话，为什么不用数据库的存储过程
我发现，大家给出来的例子，几乎都没有使用存储过程，不知道为什么，其实好多东西，都可以用存储过程实现，尤其是事务管理，我看大家都在做事务管理的配置，其实用在数据库端可以很容易的实现，尤其是jdbc现在才可以实现的回滚还原点，其实sqlserver7里面就已经可以实现了，而且存储过程编译以后在内存中，速度更快啊，而且不是可以让业务层与持久化层充分解耦么，还是我想错了，我是从DBA转过来做程序的，请大家解惑一下，谢谢
不建议使用存储过程的原因
其一： 各种数据库的存储过程语法相差很大，给将来的数据库移植带来很大的困难
其二： 不利于版本控制，代码无法Diff和回滚，多人编辑无法同步。
虽然数据库建模工具可以把脚本保存为文件，然后进行Diff，但终究功能有限。
其三： 编码不便，其实也就是说数据库脚本语言功能有限，
无法定义数组，集合，为了循环需要使用效率低下的游标
其四： 调试功能不强。
虽然在数据库客户端工具里，也可以调试,却也和现在功能强大IDE集成工具的调试
却不可同日而语。而且现在一般调试是由应用程序发起的，从应用程序却又无法
跟踪调试回存储过程中。所以必须两处调试，终究不便。
其五： 存储过程会调用函数，视图或者别的存储过程，但是数据库的编辑工具，
不像时下的开发工具，能够准确定位对象或对象方法，所以带来维护，修改的困难。
其五： 现在大多应用级系统会分层处理，数据层，业务层，界面层。
我们把大量使用存储过程的C/S或者B/S系统称为两层半，也就是说存储过程就是我们
说的半层，也就是把大量业务逻辑放在存储过程里。业务逻辑往往是系统的核心所在，
往往修改会很频繁，存储过程的使用会带来修改困难，修改流程困难，调试麻烦，
所以付出的代价是很大的。
其六： 面向业务编程，而不要面向数据编程。
面向业务编程，其实也就是之前我说的领域逻辑模式中的领域模型，也是我不赞成用存储过程
的根本原因。
如果大量用到存储过程，就势必会和数据表、字段、字段类型等等关系形数据库打交道，
面向对象的优势就体现不了，也就无从谈起继承，多态，设计模式等来适应业务变化。
很多J2EE的项目甚至不用存储过程，也照样开发的很好。
其七： 也许会遇到业务逻辑特别复杂的情况，遇到这种情况，我的感觉是你应该回头看看业务建模是否合理。
资料参考：[url]http://www.cnblogs.com/jes_shaw/archive/2009/05/20/1468505.html[/url]
在我认为，事物管理不仅仅是rollback，commit那么简单，否则就叫数据管理了