ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bertelsen, Mattias" <mbertel...@pointserve.com>
Subject RE: read-write cache with external transaction manager
Date Tue, 21 Nov 2006 16:57:04 GMT
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:mbertelsen@pointserve.com] 
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


Mime
View raw message