博客园_Technologies Kingdom

Java事务杂记

2011-03-24T09:03:00Z

关于ibatis, 连接池,事务的总结:

1. ibatis和proxool配合。session.close()并不真正调用connection.close(). 而proxool采用委托动态代理的方式替换了connection.close()实现，必须调用connection.close()方可回收链接，而非真正物理断开。所以我们使用了proxool连接池后，每次使用完session, 都要session.getConnection.close();

2. ibatis 3 + spring的事务并没有内部支持，所以无法在spring+ibatis 3默认采用生命式事务,需要额外写个针对ibatis 3声明式事务的TransactionManager实现.上次发给chris的有类似实现.

3. mysql innodb引擎方可支持事务和级联引用完整性;

4. jdbc 3方可支持savePoints()分阶段回滚. e.g.:

Savepoint sp1 = connection.setSavepoint("savePoint 1");

...

connection.rollback(sp1);

java.sql.Savepoint 必须存在, 即 jdk 版本要 1.4+;

MySQL InnoDB引擎从MySQL 5.0.3开始支持SAVEPOINT(详见: http://dev.mysql.com/doc/refman/5.0/en/savepoint.html);

5. spring托管的事务可支持: 同一连接的数据库事务，跨分布式数据库的JTX分布式事务;

6. spring声明式事务的事务级别浅显含义:

PROPAGATION_REQUIRED: 传承当前上下文事务，若当前上下文没有事务，则创建一个新事务;这是最常见的选择。

PROPAGATION_SUPPORTS: 支持当前上下文事务，若当前上下文没有事务，则以非事务方式执行;也即事务可选;

PROPAGATION_MANDATORY: 当前上下文必须存在事务;若当前上下文没有事务,则抛出异常;

PROPAGATION_REQUIRES_NEW：忽略当前上下文事务，总是创建新事务,挂起上下文事务直到新事务结束; 也即外部事务成败不影响当前事务结果;

PROPAGATION_NOT_SUPPORTED: 忽悠当前上下文事务，以非事务方式;

PROPAGATION_NEVER: 不允许在事务上下文中执行，若当前上下文存在事务，则抛出异常;

PROPAGATION_NESTED: 内嵌事务(EJB中没有对等概念), 只在某些transactionManager中支持.只在JDBC 3.0+的DataSourceTransactionManager中支持;

如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则进行与PROPAGATION_REQUIRED类似的操作。

前六个策略类似于EJB CMT，第七个（PROPAGATION_NESTED）是Spring所提供的一个特殊变量。

它要求事务管理器或者使用JDBC 3.0 Savepoint API提供嵌套事务行为（如Spring的DataSourceTransactionManager）

7. ibatis 3的事务操作注意事项:

1). 开启session方式: SqlSession session = sessionFactory.openSession(TransactionIsolationLevel.READ_COMMITTED);

2). 设置非自动commit(否则每条语句都被当作一个事务): session.getConnection().setAutoCommit(false);

3). 提交注意事项: session.getConnection().commit(); 采用session.commit()无效，很诡异; 估计session.rollback()也无效;

4). 如果部分语句需要采用批量操作(e.g.: addBatch): 则可用同一connection来创建一个新的session:

SqlSession session1 = sessionFactory.openSession(ExecutorType.BATCH, session.getConnection() );

不过有个诡异事情: 测试发现JDBC批量操作的效率反而不如直接插入;网上也有其他人同样反馈;

8. 综合来看，若能采用spring的生命式事务，是最好的选择。最灵活，可透明支持本地(同一数据库连接) 和分布式事务(通过JTX分布式事务实现);

参考:

http://www.javaeye.com/topic/35907

本文链接

UCenter的安全漏洞

2009-12-12T17:56:00Z

今天随便看了下Ucenter和uchome的统一账户机制。感觉设计上面不是很合理.如果想让某应用a在登录时同时也登录其它挂接到对应ucenter的应用b(入uhome).那么应该采用synlogin方式.

周末开发的一个Google Wave类似的评论系统

2009-12-02T08:39:00Z

周末用app engine随便做了个google wave类似的评论系统demo地址是: http://xiaoyuan-huodong.appspot.com/

CloudHosting平台Eucalyptus分析.

2009-10-20T09:05:00Z

Eucalyptus架构特征非侵入式高度模块化(highly modular cooperative) 采用公开,标准的通信协议 API与AWS兼容(SOAP & REST)

Hadoop Ecosystem解决方案---数据仓库

2009-10-14T10:27:00Z

个人总结的一套基于hadoop的海量数据挖掘的开源解决方案.

关于HDFS数据Checksum

2009-09-24T16:47:00Z

Datanode在把数据实际存储之前会验证数据的校验和.client通过pipeline把数据写入datanode. 最后一个datanode会负责检查校验和.当client从datanode读取数据时,也会检查校验和: 把真实数据的校和合同datanode上的校验和进行比较.

hadoop MapReduce Job失效模型

2009-09-07T18:07:00Z

hadoop设计的初衷就是容错.计算任务(MapReduce task)能够在节点宕机或其它随机错误下自行恢复.但是hadoop并不完美,在实际运营中,我发现MapReduce Job仍然经常会因为一些偶发性错误而运行失败.所以我决定深入探究一下各种不同因素是如何导致job失败的.如果一个hadoop job的某个给定task在失败预定次(默认是4)后,整个job就会失败.这可以通过"mapred.map.max.attempts"和"mapred.reduce.max.attempts"属性来设置.一个task可能由于各种偶发原因而失败 - 比如我发现的情况就有磁盘满,hadoop本身的bug,或者硬件失效(e.g.: 磁盘只读).

设计遐想---基于Google App Engine的IM

2009-09-01T08:57:00Z

聊天模式无非点对点聊天和群组聊天.下面一一来分析.1. Peer-to-Peer聊天消息格式:[from, to, body, timestamp, isread].(根据from来识别是个人还是group消息)消息读取方式标记模式置位模式是否要存储:不需要需要[Group Chatting]:标记模式每个用户拥有一个timestamp类型的消息游标.(sequence number不利于shar...

系统容灾备份选型的决策表

2009-08-27T09:34:00Z

分布式系统的3个特征 - consistency, availability, partition tolerance - 只能选其二.

GAE技巧汇总

2009-08-25T17:53:00Z

关于Google App Engine应用开发的一些技巧