|
From: Brandon G. <ma...@ph...> - 2004-05-29 15:13:22
|
I know I should be adding these to a bug report. But, I figured that I could
do it all in one bug report once the more complex issue of transaction
management is resolved.
I have found another issue that needs to be remedied.
Line 54 of SqlMapClientOpertaions:
List queryForList(String statementName, Object parameterObject, RowHandler
rowHandler)
throws DataAccessException;
should be..
void queryWithRowhandler(String statementName, Object parameterObject,
RowHandler rowHandler)
throws DataAccessException;
Line 185-192 of SqlMapClientTemplate needs to be changed in a similar
manner:
public List queryForList(final String statementName, final Object
parameterObject,
final RowHandler rowHandler) throws DataAccessException {
return executeWithListResult(new SqlMapClientCallback() {
public Object doInSqlMapClient(SqlMapExecutor executor) throws
SQLException {
return executor.queryForList(statementName,
parameterObject, rowHandler);
}
});
}
Should be:
I am assuming you do not want to implement another method on your
SqlMapClientCallback just to accommodate the queryWithRowHandler. So, I
simply pass back a null from the doInSqlMapClient of the
SqlMapClientCallback implementation and ignore it.
public void queryWithRowHandler(final String statementName, final Object
parameterObject,
final RowHandler rowHandler) throws DataAccessException {
executeWithRowHandler(new SqlMapClientCallback() {
public Object doInSqlMapClient(SqlMapExecutor executor) throws
SQLException {
executor.queryWithRowHandler(statementName,
parameterObject, rowHandler);
return null;
}
});
}
Also, the following should be added to the SqlMapClientTemplate
/**
* Execute the given data access action on a SqlMapSession
* with a RowHandler.
* @param action callback object that specifies the data access action
* @return the List result
* @throws DataAccessException in case of SQL Maps errors
*/
public void executeWithRowHandler(SqlMapClientCallback action) throws
DataAccessException {
execute(action);
}
Apart from all of this I am rather curious about the purpose the
SqlMapClientCallback? I read the javadoc and am wondering what role it plays
in the process of Spring integration with iBatis. Could you provide me with
a explanation of it's role?
Thanks,
Brandon Goodin
http://www.ibatis.com
_____
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Brandon Goodin
Sent: Friday, May 28, 2004 10:42 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Ibatis integration corrections
needed
Also, after some exploration I have discovered that Spring requires that the
Datasource be set via the <property name="dataSource"> on the SqlMapDaos.
This is not good. What happens when someone wants to allow iBatis to manage
transactions on it's own? I think that the datasource requirement needs to
be removed. Setting the datasource via spring should be optional not
required.
Brandon Goodin
http://www.ibatis.com
_____
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Brandon Goodin
Sent: Friday, May 28, 2004 6:57 PM
To: spr...@li...
Subject: [Springframework-developer] Ibatis integration corrections needed
Greetings,
My name is Brandon Goodin. I am committer on the iBatis project. As I've had
time recently I've become increasingly more familiar with the Spring product
and began to explore the code base. I specifically have examined the iBatis
integration and noticed a problem in how the datasource is being set.
In the SqlMapClientTemplate the execute method is using
session.setUserConnection(con);. Setting the connection using
setUserConnection on the SqlMapSession will not take full advantage of
ibatis functionality (i.e. lazy loading will not work).
The short explanation is that Spring needs to set the the Datasource via the
TransactionConfig which is stored in the TransactionManager. The
TransactionManager needs to be set via the SqlMapExecutorDelegate of the
SqlMapClient. The TransactionManager contains the TransactionConfig which
contains the datasource and various other pertinent config info for
transactions.
Following is a chunk from the XmlSqlMapClientBuilder that demonstrates how
the datasource should be configured in ibatis:
---- start code ---
TransactionManager txManager = null;
try {
errorCtx.setMoreInfo("Check the transaction manager type or class.");
TransactionConfig config = (TransactionConfig) Resources.instantiate(type);
config.setDataSource(dataSource);
config.setMaximumConcurrentTransactions(client.getDelegate().getMaxTransacti
ons());
errorCtx.setMoreInfo("Check the transactio nmanager properties or
configuration.");
config.initialize(initProperties);
errorCtx.setMoreInfo(null);
txManager = new TransactionManager(config);
} catch (Exception e) {
if (e instanceof SqlMapException) {
throw (SqlMapException) e;
} else {
throw new SqlMapException("Error initializing TransactionManager. Could not
instantiate TransactionConfig. Cause: " + e, e);
}
}
client.getDelegate().setTxManager(txManager);
--- end code ---
From what I can tell Spring allows for iBatis users to take advantage of the
iBatis transaction facilities if they choose (i.e. avoid using spring
transaction management if they so choose). So, the only thing that is left
is for Spring to use the proper implementation of the TransactionConfig
(com.ibatis.sqlmap.engine.transaction.external.ExternalTransactionConfig)
for the configuration of the datasource. The ExternalTransactionConfig will
allow for Spring to manage the commit and rollback functionality without
losing valuable functionality in iBatis (lazy loading).
I'd be happy to work on the Spring code base if you would like or provide
you with more insight if you need. Let me know.
Thanks,
Brandon Goodin
http://www.ibatis.com <http://www.ibatis.com/>
|