Java事務雜記

關於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