I'll reply to my own message for posterity:
The EXTERNAL transaction manager is not JTA-aware, it just does nothing (assuming a JTA-aware DataSource will handle commits/rollbacks) if you use the SqlMapClient transaction demarcation. However, the functionality hinted at by the documentation (automatic session management per thread) is controlled by the iBATIS transaction demarcation methods. So you must either explicitly control the session or use the iBATIS transaction demarcation (one or the other) in order for the session to persist across calls to the SqlMapClient and see the 1st level caching work with an external transaction manager. So even though it looks redundant, you have to do something like this (ignore the UserTransaction if you're using container-managed JTA transactions): UserTransaction utx = getUserTransactionFromJNDI(); utx.begin(); sqlMap.startTransaction(); server = (ServerInfo) session1.queryForObject("ServerInfo.getServer", id); server = (ServerInfo) session1.queryForObject("ServerInfo.getServer", id); sqlMap.commitTransaction(); // not sure if this is necessary if you're just reading sqlMap.endTransaction(); utx.commit(); Folks - did I get this right? ________________________________ From: Bertelsen, Mattias [mailto:[EMAIL PROTECTED] Sent: Friday, November 17, 2006 3:34 PM To: user-java@ibatis.apache.org Subject: read-write cache with external transaction manager We're having a problem with read-write non-serializable caching, using an external transaction manager (JTA) and JBoss's local-tx datasource. This refers to iBATIS 2.1.7.597 and the docs that shipped with it. In the pdf Data Mapper Developer Guide, it says that with a read-write cache, caching will only happen within each session. It also is mentioned in the pdf as well as the javadoc for the SqlMapClient that the SqlMapClient is supposed to handle a session per thread automatically. So I assume that I should see caching associated with each thread using a SqlMapClient without needing to explicitly manage the sesssions. However, we see different caching behavior when explicitly using sessions from when we don't: In our test code, we find that the following usage results in only one SQL PreparedStatement being executed (the second apparently does hit the cache): utx.begin(); if (id > 0) { SqlMapSession session1 = sqlMap.openSession(); server = (ServerInfo) session1.queryForObject("ServerInfo.getServer", id); server = (ServerInfo) session1.queryForObject("ServerInfo.getServer", id); session1.close(); } utx.commit(); While the following code shows two SQL PreparedStatements being executed: utx.begin(); if (id > 0) { server = (ServerInfo) sqlMap.queryForObject("ServerInfo.getServer", id); server = (ServerInfo) sqlMap.queryForObject("ServerInfo.getServer", id); } utx.commit(); Are we missing something? Is this a bug, or did we just not understand how the sqlMap's "automatic" session management is supposed to work for us? Thanks, Mattias Bertelsen