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 < [EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]>: > > 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 <[EMAIL PROTECTED]> > 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. > > > > > > > > > > > > >
