spring transaction的问题 - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Java - 爪哇娇娃

spring transaction的问题

spring transaction的问题# Java - 爪哇娇娃

d*g2009-04-09 07:04

1 楼

我们现用系统是.net web_form架构，数据端是oracle，我们的business逻辑基本上都
是写在数据库层，很长很长的stored procedure的数据层，ASP网页基本上就只是处理
UI和一种数据的validate，VB Class都是call写好的stored procedure。
当前用户有60万，潜在用户会上100万，每天用户的访问量倒不大，大概几万人。系统
从ASP到ASP.net已有上十年了。
我们想改系统，请问用什么架构比较合适？看大家都用MVC,是不是这是当前最好的，以
我介绍的情况，在架构与设计上大家有什么好的建议？
总觉得MS的东西一堆堆的，抱怨不好用的人也很多。如果想增加这方面的知识，有什么
书可推荐吗？
多谢了！

g*g2009-04-09 07:04

2 楼

我有一个spring bean，里面有一个方法。大致就是每发一个email, 然后修改
一些数据库的值。这个方法要对一个List做这样的操作。
我用spring 的TransactionProxyFactoryBean来做这个操作，并没有问题。
所有email先发出去，然后Transaction才commit。
现在设计需要修改一下，希望每发一个email，数据库修改就commit一次。
于是我把这些代码单独拉出来做成一个public的方法notifyRecipientsTx，
并设成PROPAGATION_REQUIRES_NEW，但发现每次调用这个方法的时候并没有
产生一个新的transaction。这是什么引起的呢？是不是因为在同一个类里面，
没有透过spring的proxy来获得bean，所以不行？除了用programmatic transaction，
有什么好的办法？这个spring bean的定义如下
class="org.springframework.t

N*n2009-04-09 07:04

3 楼

如果LOGIC主要在SP里面那就没什么好变化的。MVC是给那些LOGIC放在中间层的
程序用的。过去WEBFORM不强制分层，很多糙快猛的做法就是UI和BUSINESS逻辑
都放在一起，既不清晰又难测试，再加上一堆SESSION STATE难以SCALE所以才
重拾DESKTOP上面的MVC结构。

g*g2009-04-09 07:04

4 楼

It seems self-invocation is the problem for AOP, I have to find a way to
refactor the code and basically make this function in another bean so it's
called on a proxy, or I have to use aspectJ, ft.

【在 g*****g 的大作中提到】

: 我有一个spring bean，里面有一个方法。大致就是每发一个email, 然后修改
: 一些数据库的值。这个方法要对一个List做这样的操作。
: 我用spring 的TransactionProxyFactoryBean来做这个操作，并没有问题。
: 所有email先发出去，然后Transaction才commit。
: 现在设计需要修改一下，希望每发一个email，数据库修改就commit一次。
: 于是我把这些代码单独拉出来做成一个public的方法notifyRecipientsTx，
: 并设成PROPAGATION_REQUIRES_NEW，但发现每次调用这个方法的时候并没有
: 产生一个新的transaction。这是什么引起的呢？是不是因为在同一个类里面，
: 没有透过spring的proxy来获得bean，所以不行？除了用programmatic transaction，
: 有什么好的办法？这个spring bean的定义如下

s*o2009-04-09 07:04

5 楼

这个系统的焦点是business logic embedded in SP。出了问题不但极难debug，也很容
易造成performance bottleneck，还有scalability的问题，等等。表现层用Web Forms
还是MVC，我觉得倒不是什么大问题,够用就行了。如果是新项目，上MVC则是顺理成章
的事。
另外M$的东西可抱怨的地方有很多很多，但不好用肯定不是其中之一

t*e2009-04-09 07:04

6 楼

Just call the flush method explicitly, assuming the app has Hibernate/JPA
running underneath. ORM solutions always defer database commit to reduce IO and improve performance.

d*g2009-04-09 07:04

7 楼

多谢两位。
其实我就不喜欢business logic embedded in SP，可是看样子他们还是要坚持，主要
是不好debug和test，performance bottleneck，还有scalability的问题我倒没有深刻
体会到。
保留的原因无外忽他们认为速度快一些，再有大量的东西不用重写。
这里的人倒都不错，可是接触新技术的机会很少，时常工作多，系统服务时间已经这么
久了，不敢大改。
现在有机会重写了，没有有经验的架构师，实在是没有头续。
为什么说如果是新项目，上MVC则是顺理成章的事。我们这算是新项目吧，只是还是要
用oracle，以用很有可能保留大量已有的stored procedure.
请再给点建议吧。多谢。
另外，觉得MS的sharepoint挺不好用的，一堆功能，想要的却很难实现，不喜欢。

g*g2009-04-09 07:04

8 楼

I am using hibernate, Tried that, didn't work.

IO and improve performance.

【在 t*******e 的大作中提到】

: Just call the flush method explicitly, assuming the app has Hibernate/JPA
: running underneath. ORM solutions always defer database commit to reduce IO and improve performance.

s*o2009-04-09 07:04

9 楼

SP速度快只是就单独运行那段script而言。这点好处抵消不了带来的种种弊端。不过要
把business logic分离出来，你们的DBA大概会很生气。大量东西不用重写这条理由倒
是很solid。
Web Forms已经完成它的历史使命了，不用MVC也没啥别的好选。或者你们可以更激进一
点上Web API + Client-side JS。如果不是必须用微软技术，那选项就多了。

【在 d****g 的大作中提到】

: 多谢两位。
: 其实我就不喜欢business logic embedded in SP，可是看样子他们还是要坚持，主要
: 是不好debug和test，performance bottleneck，还有scalability的问题我倒没有深刻
: 体会到。
: 保留的原因无外忽他们认为速度快一些，再有大量的东西不用重写。
: 这里的人倒都不错，可是接触新技术的机会很少，时常工作多，系统服务时间已经这么
: 久了，不敢大改。
: 现在有机会重写了，没有有经验的架构师，实在是没有头续。
: 为什么说如果是新项目，上MVC则是顺理成章的事。我们这算是新项目吧，只是还是要
: 用oracle，以用很有可能保留大量已有的stored procedure.

m*t2009-04-09 07:04

10 楼

Yes, that's pretty much it. It's a known limitation of spring aop.

【在 g*****g 的大作中提到】

: It seems self-invocation is the problem for AOP, I have to find a way to
: refactor the code and basically make this function in another bean so it's
: called on a proxy, or I have to use aspectJ, ft.

w*72009-04-09 07:04

11 楼

如果公司想upgrade系统，扩展功能，把逻辑层和数据层分离是必须的。而mid-tier是
EF，SOAP 还是Restful，现在的趋势是越来越趋向于Restful API了。
前端如果是mobile的话用MVC+jQuery Mobile还是很不错的。

s*e2009-04-09 07:04

12 楼

As magicfat said, it is spring's limitation.
to understand this, I just want to add my two cents.
Basically, there are three types of AOP
1. like aspectj, the aspect will be woven during compilation time
2. like jboss, the aspect will be woven during class loading time.
3. like spring, the aspect will be woven during run time. And remember that
everything(almost true) in spring is singleton.
Put this together, you can see that there is no easy way for spring to solve
this limitation.

H*g2009-04-09 07:04

13 楼

nothing about MVC.
MVC is just for the presentation layer.
Looks like you need a Data Layer and a Business Layer.
For the data layer, try nHibernate, since you are using Oracle. Map all the
tables from the database into classes.
SoA is my recommendation for the business layer. The Request-Response
pattern is very nice to have.
People are lazy, therefore, if it is a solid working product, it is not
necessary to make any change. :P

【在 d****g 的大作中提到】

: 我们现用系统是.net web_form架构，数据端是oracle，我们的business逻辑基本上都
: 是写在数据库层，很长很长的stored procedure的数据层，ASP网页基本上就只是处理
: UI和一种数据的validate，VB Class都是call写好的stored procedure。
: 当前用户有60万，潜在用户会上100万，每天用户的访问量倒不大，大概几万人。系统
: 从ASP到ASP.net已有上十年了。
: 我们想改系统，请问用什么架构比较合适？看大家都用MVC,是不是这是当前最好的，以
: 我介绍的情况，在架构与设计上大家有什么好的建议？
: 总觉得MS的东西一堆堆的，抱怨不好用的人也很多。如果想增加这方面的知识，有什么
: 书可推荐吗？
: 多谢了！

s*e2009-04-09 07:04

14 楼

spring (with aspectj) also have loading time weaving with its spring-agent.jar.
but for lz's specific problem, i think refactoring to avoid self-invocation
is the best way.

that
solve

【在 s******e 的大作中提到】

: As magicfat said, it is spring's limitation.
: to understand this, I just want to add my two cents.
: Basically, there are three types of AOP
: 1. like aspectj, the aspect will be woven during compilation time
: 2. like jboss, the aspect will be woven during class loading time.
: 3. like spring, the aspect will be woven during run time. And remember that
: everything(almost true) in spring is singleton.
: Put this together, you can see that there is no easy way for spring to solve
: this limitation.

H*g2009-04-09 07:04

15 楼

抱怨不好用的人也很多, means those people basically knows nothing but
complaining. They could use WordPress, brainless product. :)

【在 d****g 的大作中提到】

t*e2009-04-09 07:04

16 楼

Internal method calls bypass AOP proxy in Spring as well as Seam. The
keyword "this" is tough to handle in the proxy object.
There is a workaround, using Spring/Seam API to locate a proxied "this" bean, and invoking the internal method on the proxied "this".
In Spring, BeanFactory.getBean("this bean");
In Seam, Component.getInstance("this bean");

x*u2009-04-09 07:04

17 楼

"再有大量的东西不用重写。这里的人倒都不错，可是接触新技术的机会很少，时常工
作多，系统服务时间已经这么久了，不敢大改。
That's one of the most important consideration in this kind of project. You
don't want to break the existing system just so you can use a new
architecture that's better in theory.
The only reason to switch architecture is if there are business needs that
requires a switch, such as a predicted increase in users that would
overwhelm the current system.
Otherwise, the project, company and the project team would all be better
served by staying in the current environment.

【在 d****g 的大作中提到】

N*n2009-04-09 07:04

18 楼

对AZURE WEBSITE架构感兴趣的可以看看下面这个链接，作为入门视频足够了。
http://channel9.msdn.com/Events/Build/2014/3-626

H*g2009-04-09 07:04

19 楼

你太可怜了，整天被GOODBUG那个二货喷，哈哈。

【在 N********n 的大作中提到】

: 对AZURE WEBSITE架构感兴趣的可以看看下面这个链接，作为入门视频足够了。
: http://channel9.msdn.com/Events/Build/2014/3-626

d*g2009-04-09 07:04

20 楼

thanks, i dont realy understand how this mapping is good. if i need to query
on different tables, many where conditions, how are the classes going to
support?

the

【在 H*******g 的大作中提到】

: nothing about MVC.
: MVC is just for the presentation layer.
: Looks like you need a Data Layer and a Business Layer.
: For the data layer, try nHibernate, since you are using Oracle. Map all the
: tables from the database into classes.
: SoA is my recommendation for the business layer. The Request-Response
: pattern is very nice to have.
: People are lazy, therefore, if it is a solid working product, it is not
: necessary to make any change. :P

d*g2009-04-09 07:04

21 楼

我没有具体测试过，不过我的理解是速度影响会很大的，比方说如果你的逻辑在应用层
，那么你得多次访问数据库，更多的数据在两层之间传递，在应用层还得用无数的变量
存储数据，这样的话不是不如什么东西在数据库层就解决了好吗？

【在 s***o 的大作中提到】

: SP速度快只是就单独运行那段script而言。这点好处抵消不了带来的种种弊端。不过要
: 把business logic分离出来，你们的DBA大概会很生气。大量东西不用重写这条理由倒
: 是很solid。
: Web Forms已经完成它的历史使命了，不用MVC也没啥别的好选。或者你们可以更激进一
: 点上Web API + Client-side JS。如果不是必须用微软技术，那选项就多了。

N*n2009-04-09 07:04

22 楼

HOHO, IT以前被我打脸心里恨得要死，到处追着我要把面子找回来。

【在 H*******g 的大作中提到】

: 你太可怜了，整天被GOODBUG那个二货喷，哈哈。

d*g2009-04-09 07:04

23 楼

呵呵，你们俩都太有个性了点，低一次头又不会死。

【在 N********n 的大作中提到】

:
: HOHO, IT以前被我打脸心里恨得要死，到处追着我要把面子找回来。

s*o2009-04-09 07:04

24 楼

数据库虽然是专门用来处理数据的，但SQL不是用来写business logic的，如果有一堆
join，subquery在那，很难想象效率能高到哪里去。多次访问数据库除非搞出N+1这类
bug没有你想象的那么严重，况且不用SP并不意味这一定要多次访问数据库。你们真想
改这块的话应该先跑几个prototype测试一下实际情况。不过如好几位指出的那样，系
统还很健壮的时候不改的理由更充分，省点时间玩玩游戏或者上mit看goodbug-
neverlearn打架更有意义

【在 d****g 的大作中提到】

: 我没有具体测试过，不过我的理解是速度影响会很大的，比方说如果你的逻辑在应用层
: ，那么你得多次访问数据库，更多的数据在两层之间传递，在应用层还得用无数的变量
: 存储数据，这样的话不是不如什么东西在数据库层就解决了好吗？

d*g2009-04-09 07:04

25 楼

多谢，再多问一个问题。
请问大家都用什么testing environment？MS team foundation可以做automatic
testing，如果是.net前台，oracle后台，用什么测试系统合适？
我们准备重写系统，他们目前准备用HP’s Unified Functional Testing，所说可以用
在不同的开发环境里，还有我们目前最大的系统是用power builder与oracle开发的，
因为这个原因他们想用这个HP UFT，可以我们将来是要全问用.net，请问各位有什么建
议吗？
多谢了。

p*92009-04-09 07:04

26 楼

MVC 使用 EF (Entity Framework). SQL statement 理论上应该完全由 MVC 生成。但
实际上根本不可能，仍需相当多手写的SQL statements. 结果整个business layer变成
了一个 SQL + C# 的混合体。还不如干脆直接用SP来的清楚。
参见下列讨论：
http://forums.asp.net/t/1882605.aspx?Under+what+circumstances+s
http://programmers.stackexchange.com/questions/158534/pros-and-
另外， Facebook 的新实验架构：
http://www.infoq.com/news/2014/05/facebook-mvc-flux.