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