|
From: <jue...@we...> - 2004-05-29 19:49:36
|
What about initializing the iBATIS TransactionManager in the way that = you suggested, and *still* pass in transactional Connections via = setUserConnection? That could give the best of both worlds: = participating in all kinds of Spring-managed transactions, and allowing = for lazy loading. It would also avoid the need to pass the DataSource to = each and every SQL-Maps-based DAO; a single passing of the DataSource to = the SqlMapClientFactoryBean would then be sufficient. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Sa 29.05.2004 21:24 An: spr...@li... Betreff: Re: [Springframework-developer] Ibatis integration corrections = needed The problem is that we'd pass the DataSource to the iBATIS = TransactionManager here, but not Spring-managed transactional = Connections. SQL Maps would fetch its own Connections from the given = DataSource, failing to participate in Spring-managed transactions (other = than JTA). I'm aware that lazy loading won't work with Spring's current iBATIS = integration strategy. However, I'm not aware of any other disadvantages; = can you give details in that respect? I wouldn't mind letting SQL Maps create its own Connections from the = DataSource for lazy loading, if told to do so. But we'd need to figure = out a way to pass a transactional Connection in for the actual operation = (like we do currently) and still allow for lazy loading via a given = DataSource. Juergen ________________________________ Von: spr...@li... im Auftrag = von Brandon Goodin Gesendet: Sa 29.05.2004 20:48 An: spr...@li... Betreff: RE: [Springframework-developer] Ibatis integration corrections = needed The issue here of setting the datasource still remains. If you set the connection via the setUserConnection it doesn't take full advantage of ibatis. However, it is possible to allow for Spring to be the iBatis TransactionManager. You simply need to set up an EXTERNAL = TransactionConfig to use in the TransactionManager. Please review my previous code. It = shows exactly how that is set. If you feel that iBatis may need to provide = better integrtion points for Spring to take advantage of... feel free to = provide suggestions. Thanks, Brandon Goodin http://www.ibatis.com -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Saturday, May 29, 2004 11:53 AM To: spr...@li... Subject: Re: [Springframework-developer] Ibatis integration corrections needed Hi again, Brandon, 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). 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. 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). 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. Juergen ________________________________ 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. 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 =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= cti ons()); 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 --- 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/> ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |