细粒度处理事务，尽快的结束事务

  我们没有用它，也是考虑到一个请求处理有时会占用很长的时间所以没有用它。

因为系统在某些时间段并发量大，业务有比较复杂，所以要优化程序优化SQL，具体有什么好的建议吗？谢谢

由于事务的边界在service层，所以action只能调用service一次，这样才能保证业务逻辑全在同一事务内
service层业务处理很少会成为瓶颈，无非是一些增删改查
一般不需要做什么优化，因为hibernate的session缓存、延迟加载本身就很高效了，都是默认配置
个别的查询可能会成为瓶颈，可以利用p6spy+sqlprofile提供的索引建议来调优

是的。我的想法是把那些只是查询的放在一个SERVICE方法中（事务传播为readOnly），,把那些对数据有更新的动作放在另外一个方法中（事务传播为required）的。这样就不会对整个业务方法都是required了，这样是不是会要好些呢？


因为有时并发量大，每个业务操作的关联的表很多。事务这块还是要注意的吧


谢谢，我也用它们监控我的SQL。

我是这样做

我执行service后，跳到另一个action执行readonly的service
这样就不冲突了

没有必要执行service后还要帮后面一个页面查询数据，可以交给另一个action查数据

spring提供的namematch的事务方法，很支持这个做法的

action要做到delegate到service，也要fill到view中，包含部分逻辑也是合理的。

dao方法中包含部分业务逻辑也是合理的，这个是充血domian object的做法，hibernate也支持的很好，也不是不合理的...

 

楼主用的dao和hiberante orm持久对象应该是贫血模型吧？

如果并发量大，业务复杂（可能是一个长事务）的话，hibernate提供的乐观锁机制可以一定程度上缓解数据库的压力。

在我曾经做过的系统中遇到过与楼主同样的问题，我既希望在操作失败时能回滚数据库，但又不希望长时间锁住一个表（这里在并发多时会出现性能问题，也就是楼主说的阻塞）。

1.首先也是想到了将原本在1个service中的多个dao分解到不同的service中，然后在action中调用多个service（我们也是将事务声明在了service层）。这样做使用了多个数据库连接，的确能在一定程度上避免阻塞，但在一个会话中创建多个数据库连接是比较耗费资源的（使用连接池可能会好一点），更重要的是事务也不好控制。比如你的dao顺序是：
select
update
select
delete
select。

2.因为在spring框架中没有找到更好的事务配置办法，后来采用了硬编码处理sql异常来控制事务。上面的多个dao还是放在1个service中，取得连接并将使用其默认的自动提交属性设置true（即执行完一个dao就提交），分别处理各个dao抛出的异常，执行相应的dao以保持数据的一致性（相当于回滚数据库）。这样做使得锁住一个表的时间缩短从而降低了阻塞发生的几率，而且只创建1个数据库连接降低了资源耗费，缺点是编码太过繁琐，例如update还得保存之前的值用以回滚。

最后权衡了一下系统的实际情况，系统在内网使用，数据库在局域网，在一次会话过程中发生数据库异常的可能性非常小，所以，像这种情况的service，我选择了性能，放弃了事务。不知道大侠们都是如何处理这种service的？

我说的是大规模的并发环境下意见, 每天有千万以上PV的站点:
1.绝对禁止使用声明式事务
2.小心手动控制事务处理, 处理好数据准备工作, 尽量把事务在最小的代码块里完成.

这么说吧, 大规模并发环境中, 使用手动事务比声明式事物性能高3-5倍<通过长期观察得出的结论>. 而且声明事物容易发生死锁行为.
最终的解决方案, 对于基于服务的应用. 自己做事务服务器. 我知道有站点这么作的. 我目前也在做哈, 不然SOA类型的应用, 想控制事务太困难.  哈.

真会这么高效么？
声明事务覆盖的方法中如果只有一个数据库操作我觉得有没有事务都一样的。
从Spring的文档上看，似乎不是很推荐手动控制，说这样就造成了入侵性还是什么。但是说也有特殊情况。
其实我也整不明白，为什么就一个insert的方法也得声明事务。这不是找茬么。。。比如save(Entity entity)里面很简单的最终调用了HibernateTemplate.save。也是事务。