hibernate的配置文件属性:connection.autocommit=true有哪些缺点?为何不建议使用true呢????
hibernate的配置文件属性:connection.autocommit=true有哪些缺点?为何不建议使用true呢????
谢谢!
是不是这样就没有使用缓存啦?
用spring+hibenrate的HibernateTemplate,要使用事务,否则就设定connection.autocommit=true
呵呵!

------解决方案--------------------
connection.autocommit=true

这个属性是说，如果是true的话，就是自动提交，比如
在一个业务中中，你有多个操作数据库的子业务，
例如
业务SuperA中有子业务suba,subb,subc.....
如果是自动的话，
suba操作成功 提交
subb操作失败 回滚
subc操作失败 回滚

按照我们的逻辑当SuperA中有某一环节操作失败的话，都应该回滚到没有操作之前
而当为true时，则为出现a成功 b,c失败 ,SuperA不具备了时务的特征，原子性等等

当不是true时，这时事务的管理提交给了spring，Spring的事务控制是以一个bean为单位的，
SuperA是bean中一个方法或者其他，这样当执行事务SuperA时，只要a,b,c...中一个失败，都
会认定是失败操作 roolback. 这样避免了脏数据的出现，也合乎了事务的特征。。

不知道能不能看明白。。。
------解决方案--------------------
1如果connection.autocommit=true，每次‘直接’和database数据库连接，没有经过缓存了，是不是缓存的利用率下降啦? 
2另外，autocommit=true以后，代码中的‘显式声明’的事务是不是不能起作用了？


1,和缓存没关系，当整合spring时，ORM一般都是hinernate，缓存级别都是在hibernate的xml文件中设置的，一级缓存session,2级缓存sessionFactory，如果不是用orm，纯JDBC的话，缓存级别只能在数据库端设置。所以与connection.autocommit= true无关。

2，显式声明，你是说在程序中设置
connection.setautocommit(false); 
然后通过调用connection类的commit()与rollback()方法来人工的方式对事务进行管理？
如果是这样的话，你的事务时起作用的。