ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Lamey <cla...@localmatters.com>
Subject Re: How can I change datasource connect info on the fly w/iBATIS and Spring?
Date Tue, 22 May 2007 15:41:39 GMT
Hello,

I have a DataSource txn mgr for each DataSource.

Cheers,
Chris

On Tue, 2007-05-22 at 17:31 +0200, tran duc trung wrote:
> Thanks for the rapid response.
> 
> How do you specify a DataSource for DataSourceTransactionManager while
> you have several datasources (one for each SqlMapClient) ?
> 
> Trung
> 
> 2007/5/22, Chris Lamey < clamey@localmatters.com>:
>         Hello,
>         
>         I also use Spring's DataSource txn mgr with this setup (in
>         fact, I think
>         the Spring SqlMapClient can't use the iBATIS txn mgr).
>         
>         My transactions are contained in a single Thread hitting a
>         single
>         DataSource within an invocation of a method of my API.  A
>         Thread will 
>         likely end up hitting multiple DataSources over time, but that
>         ThreadLocal variable will be set upon entry into any API
>         method for the
>         life of that method.
>         
>         The Spring DataSource txn mgr essentially watches Threads
>         hitting 
>         DataSources, it really doesn't care how they come in.  There
>         is no
>         difference to the txn mgr between calls from a normal
>         SqlMapClient and
>         the RoutableSqlMapClient.  They're just method calls coming
>         into the 
>         DataSource on a per-Thread basis.  Spring basically opens a
>         transaction
>         upon a Thread's entry into my API (more or less), the txn mgr
>         then
>         batches up all the SQL generated, and when the Thread leaves
>         the API the 
>         txn mgr commits it all.
>         
>         Cheers,
>         Chris
>         
>         On Tue, 2007-05-22 at 14:12 +0200, tran duc trung wrote:
>         > I have not yet tested your solution, but how about the
>         integration
>         > with Spring Transaction Manager? 
>         > We do not have IbatisTransactionManager in Spring but have
>         to use
>         > DataSourceTransactionManager which is not notified when
>         datasource
>         > change.
>         >
>         > 2007/4/13, Chris Lamey <clamey@localmatters.com>:
>         >         Yea, Spring has a new AbstractRoutingDataSource that
>         can route
>         >         to a
>         >         different datasource based on a ThreadLocal.  The
>         problem is
>         >         that the 
>         >         iBATIS SqlMapClient doesn't know the datasource
>         isn't the same
>         >         between
>         >         calls, so your caching gets horked.
>         >
>         >         Based on the AbstractRoutingDataSource idea, I wrote
>         a 
>         >         RoutingSqlMapClient that implements the
>         ExtendedSqlMapClient
>         >         interface
>         >         and gets wired up in Spring like this:
>         >
>         >         <bean id="sqlMapClient"
>         >
>         class="com.localmatters.bo.core.util.RoutingSqlMapClient">
>         >             <property name="targetSqlMapClients">
>         >             <map
>         >         key-type="
>         com.localmatters.bo.core.commons.VendorTypes ">
>         >                 <entry key="VendorOne"
>         >         value-ref="vendorOneSqlMapClient"/>
>         >                 <entry key="VendorTwo" 
>         >         value-ref="vendorTwoSqlMapClient"/>
>         >                 <entry key="VendorThree"
>         >         value-ref="vendorThreeSqlMapClient"/>
>         >             </map> 
>         >             </property>
>         >         </bean>
>         >
>         >         Each of the "vendorXXXSqlMapClient" beans has its
>         own
>         >         datasource and
>         >         transaction handling.  The "sqlMapClient" bean is
>         then set on 
>         >         all my
>         >         DAOs.
>         >
>         >         Then have a class, VendorContextHolder, that sets a
>         >         ThreadLocal
>         >         variable that is then used by the
>         RoutableSqlMapClient as a 
>         >         key in the
>         >         targetSqlMapClients Map.  My entry points into the
>         API then
>         >         use a method
>         >         parameter to set the ThreadLocal for the that thread
>         for the
>         >         remainder 
>         >         of the call.
>         >
>         >         It's working well so far, everything works as
>         >         expected.  Transactions
>         >         are handled correctly and there's been no thread
>         stomping. 
>         >
>         >         I don't know if it'll work for you because your
>         datasources
>         >         have to be
>         >         known in advance and it sounds like yours may not
>         be.
>         >
>         >         Cheers, 
>         >         Chris
>         >
>         >         On Fri, 2007-04-13 at 12:34 -0600, Larry Meadors
>         wrote:
>         >         > You could implement a custom datasource and
>         datasource
>         >         factory to
>         >         > switch it on the fly, but I think you'd have
>         troubles with 
>         >         things like
>         >         > caching, etc.
>         >         >
>         >         > A safer implementation would have two sql map
>         clients - one
>         >         per
>         >         > datasource that you swapped instead. 
>         >         >
>         >         > Larry
>         >         >
>         >         >
>         >         > On 4/13/07, Paul Sanders <tendancer@gmail.com>
>         wrote:
>         >         > > 
>         >         > > One of the characteristics of my application is
>         that the
>         >         datasource
>         >         > > connection information can be supplied by the
>         user, and I
>         >         wonder if anyone 
>         >         > > has any advice on how to handle that?
>         >         > >
>         >         > > Currently I define a datasource in my
>         applicationcontext
>         >         with default
>         >         > > information (my test db) and specify my
>         BanPolicyDAO 
>         >         object, letting Spring
>         >         > > inject the datasource. All works well with my
>         new
>         >         BanPolicy configuration
>         >         > > (that you've all seen over and over this
>         week!). 
>         >         > >
>         >         > > I searched the archives for dealing with
>         multiple
>         >         datasources but all the
>         >         > > responses seemed to be in the case when you knew
>         the 
>         >         connection info in
>         >         > > advance. In my case I need to create a new
>         datasource on
>         >         the fly, or be able
>         >         > > to change the settings of the existing one. So
>         far my 
>         >         efforts haven't worked
>         >         > > - the DAO only ever uses the original connection
>         info.
>         >         > >
>         >         > > Anyone tried this, or have have any thoughts on
>         the best 
>         >         way to do it?
>         >         > >
>         >         > > Cheers
>         >         > >
>         >         > > Paul
>         >         > > --
>         >         > > View this message in context: 
>         >
>         http://www.nabble.com/How-can-I-change-datasource-connect-info-on-the-fly-w-iBATIS-and-Spring--tf3573169.html#a9983995
>         >         > > Sent from the iBATIS - User - Java mailing list
>         archive at
>         >         Nabble.com.
>         >         > >
>         >         > >
>         >
>         >
> 

Mime
View raw message