Re: [Springframework-developer] Ibatis integration corrections needed

[<jue...@we...>]

Hi again, Brandon,
=20
While I agree that Spring allows iBATIS users to choose between Spring's =
own transaction management and iBATIS transaction management, this does =
not necessarily affect the iBATIS support classes that we provide: Those =
classes are specifically meant to integrate SQL Maps into Spring's =
resource and transaction management, potentially sharing transactions =
with other data access strategies within Spring (for example, plain JDBC =
or Hibernate).
=20
As far as I understand, the SqlMapClient API already allows for simple =
one-line operations when using its own resource and transaction =
management. So effectively, you don't need to use Spring's =
SqlMapClientTemplate in that scenario: Simply use the SqlMapClient =
instance directly. Of course, you can still use Spring's =
SqlMapClientFactoryBean to set up your SqlMapClient in the application =
context, passing it to your DAOs via bean references.
=20
A disadvantage that I see with direct SqlMapClient usage is that you =
have to deal with checked SQLExceptions that your DAOs throw. However, =
that's also the case with your iBATIS transaction demarcation code, so =
that will be consistent throughout the application. The alternative is =
to use Spring's resource and transaction management: throwing unchecked =
DataAccessExceptions from DAOs (like SqlMapClientTemplate does), and =
unchecked TransactionExceptions from transaction demarcation code (like =
Spring's PlatformTransactionManager interface and declarative =
demarcation facilities do).
=20
So in the end, there are two choices for using Spring in combination =
with iBATIS SQL Maps: either Spring resource and transaction management =
(-> coding your DAOs with SqlMapClientTemplate), or iBATIS resource and =
transaction management (-> coding your DAOs with SqlMapClient directly). =
I don't see a need to rework SqlMapClientTemplate here: Simply use =
SqlMapClient directly in your scenario; you can still leverage all of =
Spring's IoC facilities.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Brandon Goodin
Gesendet: Sa 29.05.2004 07:42
An: spr...@li...
Betreff: 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=3D"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.

=20

Brandon Goodin

http://www.ibatis.com

=20

________________________________

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

=20

Greetings,

=20

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.

=20

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).

=20

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.

=20

Following is a chunk from the XmlSqlMapClientBuilder that demonstrates =
how the datasource should be configured in ibatis:


---- start code ---
TransactionManager txManager =3D null;
try {
errorCtx.setMoreInfo("Check the transaction manager type or class.");
TransactionConfig config =3D (TransactionConfig) =
Resources.instantiate(type);
config.setDataSource(dataSource);
config.setMaximumConcurrentTransactions(client.getDelegate().getMaxTransa=
ctions());
errorCtx.setMoreInfo("Check the transactio nmanager properties or =
configuration.");
config.initialize(initProperties);
errorCtx.setMoreInfo(null);
txManager =3D 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 ---

=20

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).

=20

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.

=20

Thanks,

Brandon Goodin

http://www.ibatis.com <http://www.ibatis.com/>=20

=20