2009年4月9日星期四

阿里软件

老婆在淘宝上做了很多年生意了,今天看了阿里软件,open api还是做的有声有色的。
现在阿里上的软件种类还不多,不知道是不是审核的比较严。。。
大家一起开发的力量要比一个公司的大很多啊。

2009年2月26日星期四

Google App Engine 开始收费

http://googleappengine.blogspot.com/2009/02/new-grow-your-app-beyond-free-quotas.html

Google App Engine开始收费,可以超过之前的配额。
不过90天后,免费的配额会有所减少。

App Engine will always remain free to get started. However, along with many performance improvements, we have learned that we were overly conservative with our initial free quota estimates. Therefore, 90 days after February 24th, 2009, we will be reducing the free quota resources. 

2009年2月13日星期五

刹那的感动

看着一位被迫离职同事走的背影,有一种说不出的感觉,是高兴还是苦涩。。。
人生就是这样的吗?

苦涩是他的离开,高兴是祝他有更好的未来。

2009年2月9日星期一

Google App Engine产品线路更新

http://googleappengine.blogspot.com/2009/02/roadmap-update.html

GAE产品线路更新。

1、支持任务调度模型
2、任务消息后台处理
3、接受和处理邮件
4、支持XMPP (Jabber) messages

都是比较重要的特性,企业开发都都是需要的。
希望不要让我们等的太久。

2009年1月31日星期六

2009年1月报

雅虎任命卡罗尔巴兹为新CEO

Android创始人离职 称谷歌精力转移至上网本

马云鼓励阿里巴巴员"去消费"

2009年1月26日星期一

新年快乐

happy牛耶你最牛!!

2009年1月22日星期四

Spring线程池(二)

还是之前的业务,使用线程池,线程池里的job的业务是去请求一个http的连接并得到返回。
在qa环境没有问题,在生产服务器上会有30%会报出connection reset的Exception。而且就是在没有量的情况下,就是生产测试随便走10笔。
线程池的配置如下
taskExecutor = new ThreadPoolTaskExecutor();
taskExecutor.setCorePoolSize(1);
taskExecutor.setMaxPoolSize(20);
taskExecutor.setQueueCapacity(10000);
taskExecutor.setDaemon(true);
taskExecutor.initialize();

connection reset看下来是因为客户端自己关闭了连接。
难道问题是出在了taskExecutor.setDaemon(true); 这个参数配置上??
这个是因为上次压力把应用压掉我尝试性的加上的。
子线程结束前,父线程就结束,所以是客户端自己关闭连接?!!!
但J2EE容器都是有线程池的,qa环境包括压力环境也没有报出这个问题!服务器的环境配置不一样?!!

在我这个改动上去之前,貌似没有这种情况了?!

加上后走了几笔也没有类似情况发生。

后续。。。。。。

2009年1月21日星期三

Spring事务切面

Spring事务控制是通过AOP的方式实现的,那也就是说必须通过了这个切面才会有事务的代理(从spring的context去取一个bean时)。 

例子1:
事务切面配置在service层
ServiceA中有两个方法a和b
方法a配置为REQUIRED
方法b配置为REQUIRES_NEW
在ServiceA中的a方法调用b方法,这个时候b的REQUIRES_NEW是不起作用的,因为外围调用了ServiceA的a方法,通过了切面,事务配置了REQUIRED。在方法a里面调用b方法,这个时候并没有通过切面,因此方法b的REQUIRES_NEW就不起作用了。
如果在ServiceB中的方法调用ServiceA中的方法b,这个时候通过了前面,因此方法b的REQUIRES_NEW就起作用了。

同理例子2:
使用JTA事务
事务切面配置在service层
ServiceA中有方法a和方法b
ServiceB中有方法c
配置Exception1为rollback-for
如果ServiceA中的方法a调用ServiceB中的方法c,方法c中抛出Exception1,方法a截获并不抛出,但最后事务提交时候还是会rollback。因为调用方法c的时候通过了切面,这个时候JTA事务起了作用,c抛出Excepion1,整个事务就标记为rollback,这个时候不管方法a时候catch住,事务都会rollback。
同样ServiceA中的方法a调用ServiceA中的方法b,方法b中抛出Exception1,方法a截获并不抛出,最后事务是可以提交的。因为调用方法b的时候是在同一个service中并没有通过切面。throws 

因此在一个大型的项目中,一开始就要为之后的开发设置好合理的切面,哪些Exception需要roolback,哪些Exception不需要rollback。

在最近的开发中发现了,Service层的接口还是需要throws特定的Exception的。
情况:
整个公司产品的切面是切在 test.*Service下的所有方法的,并试用JTA事务。一个team开发了一个接口AService中有个方法a,但并没有throws Exception,其他模块要调用这个接口,如果想要在AService的方法a抛出unCheckedException的时候并不打断外围逻辑的执行(外面的事务并不回滚)。因为接口并没有throws 特定Exception,而是会抛出unCheckedException,这个时候就没有办法配置no-rollback-for了。

2009年1月18日星期日

转:Web请求异步处理降低应用依赖风险

http://www.infoq.com/cn/articles/request-asyn-risk-reduce

文章写的很好,本质还是TCP长连接。
互联网的东西最好是一开始就能考虑下压力并发问题。