Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 78600 invoked from network); 22 May 2007 15:31:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 22 May 2007 15:31:32 -0000 Received: (qmail 96498 invoked by uid 500); 22 May 2007 15:31:35 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 96488 invoked by uid 500); 22 May 2007 15:31:35 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 96477 invoked by uid 99); 22 May 2007 15:31:35 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 May 2007 08:31:35 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of ductrung.tran@gmail.com designates 64.233.162.232 as permitted sender) Received: from [64.233.162.232] (HELO nz-out-0506.google.com) (64.233.162.232) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 May 2007 08:31:26 -0700 Received: by nz-out-0506.google.com with SMTP id q3so2597836nzb for ; Tue, 22 May 2007 08:31:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=l8qL+UTtlZ2hEhST/yYeh+L0KQOtCHxquPg3I7qN5yPZ4B2RDgZM9yuKirbsJmye37RsEaZYe/rmuFfuFQIwvZhH6wsH+PH3q6rqHC8Sk1Ei/s3TPmHa4NUSlI0/zsJHyPcCzU1gq28eZw2S8sTpPsYG08wbQDitI405hLsnM6c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=OPLKleeggBm33KIRV26O6+KTYmS0zpjGHeVF7m4niLpzm59AKaOCdkZcgj2fwB0QVbnTGo+px/C0hmDmboS3CdcfshruNxCefA2Eo076baS86xIdzu5tGMnhrJeaDyWnO+TrYLsYw9V9O0h/MpqcaZSTyQo39525yuyso/xaXcM= Received: by 10.114.52.1 with SMTP id z1mr3319529waz.1179847865532; Tue, 22 May 2007 08:31:05 -0700 (PDT) Received: by 10.115.91.10 with HTTP; Tue, 22 May 2007 08:31:05 -0700 (PDT) Message-ID: <7444444c0705220831n1a0dfb9fyccc7b00275f9897b@mail.gmail.com> Date: Tue, 22 May 2007 17:31:05 +0200 From: "tran duc trung" To: user-java@ibatis.apache.org, clamey@localmatters.com Subject: Re: How can I change datasource connect info on the fly w/iBATIS and Spring? In-Reply-To: <1179847141.18807.30.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_95010_928685.1179847865458" References: <9983995.post@talk.nabble.com> <1176490374.8582.10.camel@localhost.localdomain> <7444444c0705220512o639f11d1n85e62484ac619a79@mail.gmail.com> <1179847141.18807.30.camel@localhost.localdomain> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_95010_928685.1179847865458 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 : > > 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 : > > 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: > > > > > class="com.localmatters.bo.core.util.RoutingSqlMapClient"> > > > > > key-type="com.localmatters.bo.core.commons.VendorTypes "> > > > value-ref="vendorOneSqlMapClient"/> > > > value-ref="vendorTwoSqlMapClient"/> > > > value-ref="vendorThreeSqlMapClient"/> > > > > > > > > > > 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 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. > > > > > > > > > > > > > ------=_Part_95010_928685.1179847865458 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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.
>         > >
>         > >
>
>

------=_Part_95010_928685.1179847865458--