-
请问为什么用spring事务管理? 20
请问为什么用spring事务管理?
好像我不用spring事务管理的话,好像也不回出现什么异常情况吗
问题补充:gdfloyd 写道有利于代码重用,特别是dao代码的重用。事务往往和业务规紧密关联,当业务逻辑发生改变,意味着dao的大幅度改动。系统规模达到一定程度,修改风险相当大。Spring的好处是不更改现有的dao,仅需对现有的service bean 进行配置就达到事务效果了。同时,把事务统一在service层,系统结构更清晰
我觉得事务是数据库的事情,不是程序的事情,所以觉得没有必要用spring事务管理。 但是看了你讲的之后觉得很有道理,请再具体一点可以吗?
问题补充:pipilu 写道楼主貌似从来不在service层使用事务?!
用过,但是不知道为什么用?
问题补充:risemanjavaeye 写道不知道楼主的意思是不用事务,还是不用spring来做事务?
应用层面的事务是在业务级的,这种事务数据库管不着。要是一个应用没有事务,自己点点刷刷是没有问题的,但真正到生产环境中就不一定行了。
比如你去银行取钱,银行把钱给你,然后在你帐户中把你的余额修改,这是一个事务的,能保证你拿到钱后去你再去查你的帐户,你能立刻看到你的账户余额减少,如果没有事务,你可能去查看到的余额没有变,你会有什么感觉。这只是很简章的一方面。至于用不用spring来管理,那就是你自己的事情了。
我一直觉得事务是数据库的事情,为啥要用spring来管理呢
问题补充:julycool 写道我补充三点:
1、hibernate因为有一个flush功能,这个在flush时才会真正执行相关SQL,所以hibernate自己实现了一套事务,这个是有别于我们简单的使用jdbc的事务的,使用spring的事务可以兼顾jdbc与hibernate的情况;
2、可以使用spring做隐式事务,直接在配置文件中声明事务,这样大多通用操作不需要程序员关心事务问题,减轻错误机率;
3、说事务是数据库的事情那是从数据库编写存储过程的角度出发的,在编写存储过程时会有数据库的一套事务,我们常说的事务应该是基于jdbc的;
不要认为事务就是数据库事务,这样理解不正确,比如你持久的地方一个是物理卡,一个是数据库,那保证物理卡与数据库的数据一致难道就不是事务了么?
请问什么是物理卡,能给我一个例子说明,不用spring事务会导致什么问题吗?
问题补充:peijunlin2008 写道我觉得事务是数据库的事情,不是程序的事情,所以觉得没有必要用spring事务管理。 事务是根据你的业务来定的怎么能说是数据库的事?
你是说如果数据根据业务流程来吗,同一个数据流程中的东西一起提交或者说一起失败?2010年2月11日 09:23
27个答案按时间排序按投票排序
-
直白一点解答楼主的疑惑吧。
事务确实是数据库的事情,但是我们得要把事务的起点和终点告诉数据库吧。
如果你直接使用jdbc的话就会需要如下类似的代码:
- try{
- conn=DriverManager.getConnection("jdbc:odbc:grade");
- defaultCommit=conn.getAutoCommit();
- conn.setAutoCommit(false);
- stmt=conn.createStatement();
- stmt.executeUpdate(strSQL1);
- stmt.executeUpdate(strSQL2);
- conn.commit();
- }
- catch(Exception e){
- conn.rollback();
- e.printStackTrace();
- }
- finally{
- conn.setAutoCommit(defaultCommit);
- if(stmt!=null){
- stmt.close();
- }
- if(conn!=null){
- stmt.close();
- }
- }
就是将自动提交设为false之后,连续的几个数据库操作,如果成功的话,则提交完成一个事务,如果某个发生异常,则回滚。
而Spring的失误处理,底层也就是这样的,只是spring的方式给程序员提供了便捷,AOP,让程序员不要在关心这些重复的try catch ,只需要关心业务代码。
哈哈接分。2010年2月26日 17:27
-
关键还是个粒度问题吧,
有时候我们的操作有业务上的事务,
比如a操作和b操作必须保证原子性。
那么就需要使用事务了。
当然你自己用jdbc来写也是可以的,只是没有spring配置这么优雅灵活。2010年2月26日 17:16
-
我说的是指业务级别上的“事务”,数据库事务级别使用默认即可!除非某些特殊项目需要修改数据库的事务级别。不过,数据库的事务级别也可以通过Spring来控制的!
2010年2月25日 17:58
-
我补充三点:
1、hibernate因为有一个flush功能,这个在flush时才会真正执行相关SQL,所以hibernate自己实现了一套事务,这个是有别于我们简单的使用jdbc的事务的,使用spring的事务可以兼顾jdbc与hibernate的情况;
2、可以使用spring做隐式事务,直接在配置文件中声明事务,这样大多通用操作不需要程序员关心事务问题,减轻错误机率;
3、说事务是数据库的事情那是从数据库编写存储过程的角度出发的,在编写存储过程时会有数据库的一套事务,我们常说的事务应该是基于jdbc的;
不要认为事务就是数据库事务,这样理解不正确,比如你持久的地方一个是物理卡,一个是数据库,那保证物理卡与数据库的数据一致难道就不是事务了么?2010年2月25日 12:46
-
在你的理解里事务是什么?应用级事务和数据库级事务又是什么?我说的那个例子没有让你感觉到事务的存在吗以及他和数据库的关系,也许我们对事务的理解不一样,所以没有说到一个点上
2010年2月25日 12:03
-
我觉得事务是数据库的事情,不是程序的事情,所以觉得没有必要用spring事务管理。 事务是根据你的业务来定的怎么能说是数据库的事?
2010年2月25日 09:59
-
spring 管理事务,是利用了spring的aop通过拦截器,对事务,进行动态管理,这样创建事务管理对象,不是硬编码实现,而是通过spring容器进行管理,使程序各个部分之间少了耦合。
2010年2月24日 23:26
-
不知道楼主的意思是不用事务,还是不用spring来做事务?
应用层面的事务是在业务级的,这种事务数据库管不着。要是一个应用没有事务,自己点点刷刷是没有问题的,但真正到生产环境中就不一定行了。
比如你去银行取钱,银行把钱给你,然后在你帐户中把你的余额修改,这是一个事务的,能保证你拿到钱后去你再去查你的帐户,你能立刻看到你的账户余额减少,如果没有事务,你可能去查看到的余额没有变,你会有什么感觉。这只是很简章的一方面。至于用不用spring来管理,那就是你自己的事情了。2010年2月24日 12:00
-
就是方便了。举个例子,假如你有十个方法都是用来操作数据库的,那你是不是要将事务开启,关闭,回滚等一些操作写个十遍,当然你可能会使用模板方法,但是它还是要你自己写这些关于事务开启,关闭,回滚的代码的。用spring事务管理,你就不用写这些代码了,它会在你执行方法之前自动开启事务,结束关闭事务。
2010年2月23日 19:27
-
没事务不报异常?那是因为你没真正用到,,有事务可以回滚,,如果处理到一半一些数据已经加入到数据库,一些还没有加入时就出现异常???这时候你看下有没有问题。。。。
2010年2月23日 17:21
-
首先说不用事务管理会发生异常的。例如在取款机取钱,你取5000元,输入了金额,但是取款机没这么多钱,却照样扣了你5000元。这样你就会损失了。有了事务,事务具有acid特性,要么把事件都执行,要么都不执行。这时候上述情况就不会发生。当然,spring管理事务有很多优点,是轻量级的,出现异常自动回滚,自动提交。一般把事务配置在业务层。
2010年2月22日 09:16
-
事务都是放在service层的,
使用spring来管理事务的话,可以把事务代码抽取出来,
这样的话,service层的代码简洁了,同时也降低了耦合度。
这一点对大项目来说尤其重要的。
aop确实是强大。2010年2月21日 17:13
-
逻辑可以用在存贮过程里,那样在移植的时候,会出现问题!当然不涉及移植的,就都一样!写在代码里,用spring的事务管理,简单,高效!灵活使用就行了。
2010年2月20日 13:32
-
事务往往和业务规紧密关联,用sql把业务逻辑写在procedure,funtion就所谓是数据库的事情,用java把业务逻辑写在代码里就所谓是程序的事情。把事务交给spring来管理,就把业务逻辑一定程度从sql和java代码中分离出来,放在配置文件/注解来统一管理,从而实现了系统的低耦合高伸缩
2010年2月20日 09:15
-
有利于代码重用,特别是dao代码的重用。事务往往和业务规紧密关联,当业务逻辑发生改变,意味着dao的大幅度改动。系统规模达到一定程度,修改风险相当大。Spring的好处是不更改现有的dao,仅需对现有的service bean 进行配置就达到事务效果了。同时,把事务统一在service层,系统结构更清晰
2010年2月11日 10:43
-
个人认为:
Spring的事务管理是管理的是数据库事务。你自己控制事务也可以。但是代码繁琐。