You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Chris Lamey <cl...@localmatters.com> on 2007/04/13 20:52:54 UTC
Re: How can I change datasource connect info on the fly w/iBATIS
and Spring?
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 <te...@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.
> >
> >
Re: How can I change datasource connect info on the fly w/iBATIS
and Spring?
Posted by Paul Sanders <te...@gmail.com>.
Chris Lamey wrote:
>
> That should work ok, that Map could get modified at servlet init time.
>
Drat, doesn't appear to, at least not how I've written it. I think there are
two problems - first, the map is already set by the time my servlet gets
created and a call to setTargetDataSources will not overwrite it. Second,
the map is String to String, rather than a key to a dataSource name. But I
don't know how to give my dataSource a name in the context when it doesn't
come from a config file.
Here's what I did - maybe I did something stupid:
my bean def:
<bean id="mediusDataSource" class="MediusRoutingDataSource">
<property name="targetDataSources">
<map>
<entry key="medius1" value-ref="mediusSource" />
<entry key="medius2" value-ref="oldSource" />
</map>
</property>
</bean>
public class MediusRoutingDataSource extends AbstractRoutingDataSource
{
protected static boolean didOnce = false;
@Override
protected Object determineCurrentLookupKey()
{
if (didOnce) return "xxxMedius";
else { didOnce = true; return "medius2";}
}
}
test code:
public void testGetBanPoliciesFromDifferentSource()
{
BanPolicyManager mgr = (BanPolicyManager)ctx.getBean("banPolicyDAO");
System.out.println(mgr.fetchBanPolicies()); // uses 'medius2' datasource,
returns empty list
BasicDataSource newDS = new BasicDataSource();
newDS.setUsername("psanders");
newDS.setUrl("jdbc:oracle:thin:@toad002:1521:sid");
newDS.setPassword("psanders");
newDS.setDriverClassName("oracle.jdbc.driver.OracleDriver");
MediusRoutingDataSource mds =
(MediusRoutingDataSource)ctx.getBean("mediusDataSource");
// some code omitted to create a Map<String, BasicDataSource>
routingMap.put("xxxMedius", newDS); // add new datasource to the routing
map
mds.setTargetDataSources(routingMap);
System.out.println(mgr.fetchBanPolicies()); // now uses 'xxxMedius'
datasource
// exception raised java.lang.IllegalStateException: Cannot determine
target DataSource for lookup key [xxxMedius]
}
--
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#a10047766
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
Re: How can I change datasource connect info on the fly w/iBATIS
and Spring?
Posted by Chris Lamey <cl...@localmatters.com>.
That should work ok, that Map could get modified at servlet init time.
On Tue, 2007-04-17 at 11:27 -0700, Paul Sanders wrote:
> Hmm... I wonder if it would be possible to update the datasource mapping
> later? Its true that I don't know the datasources at init time but I do know
> them as soon as the first servlet class is loaded. Can the targetDataSource
> Map get updated after the AbstractRoutingDataSource has been created?
>
> Paul
>
> Chris Lamey wrote:
> >
> > 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.
> >
> > 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
> >
>
>
Re: How can I change datasource connect info on the fly w/iBATIS
and Spring?
Posted by Paul Sanders <te...@gmail.com>.
Hmm... I wonder if it would be possible to update the datasource mapping
later? Its true that I don't know the datasources at init time but I do know
them as soon as the first servlet class is loaded. Can the targetDataSource
Map get updated after the AbstractRoutingDataSource has been created?
Paul
Chris Lamey wrote:
>
> 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.
>
> 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
>
--
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#a10043460
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
Re: How can I change datasource connect info on the fly w/iBATIS
and Spring?
Posted by Chris Lamey <cl...@localmatters.com>.
Hello,
I switched to the Spring 2.0 AOP stuff a while back, so I have something
like this for each DataSource (mine are on a per-vendor basis):
<bean id="vendorOneTransactionManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="vendorOneDataSource"/>
</bean>
<aop:config>
<aop:pointcut id="vendorOneNontologyManagerOperation"
expression="execution(*
com.localmatters.bo.core.nontology.manager.*Manager.*(..))"/>
<aop:pointcut id="vendorOneNontologyDAOOperation"
expression="execution(*
com.localmatters.bo.core.nontology.dao.ibatis.*DAO.*(..))"/>
<aop:advisor advice-ref="vendorOneTxAdvice"
pointcut-ref="vendorOneNontologyManagerOperation"/>
<aop:advisor advice-ref="vendorOneTxAdvice"
pointcut-ref="vendorOneNontologyDAOOperation"/>
</aop:config>
<!-- the transactional advice -->
<tx:advice id="vendorOneTxAdvice"
transaction-manager="vendorOneTransactionManager">
<tx:attributes>
<!-- all methods starting with 'get' or 'select' are
read-only -->
<tx:method name="get*" read-only="true"/>
<tx:method name="select*" read-only="true"/>
<!-- other methods use the default transaction settings -->
<tx:method name="*"/>
</tx:attributes>
</tx:advice>
All methods on the Manager and DAO classes that do not start with get or
select are then wrapped in their own transaction.
I don't know how you'd do it for the old Spring style. Maybe you'd have
multiple TransactionProxyFactoryBean beans that all target the same
service?
Cheers,
Chris
On Tue, 2007-05-22 at 18:30 +0200, tran duc trung wrote:
> Hi,
>
> So how do you set a tx mrg for a service. Normally, i have a service
> configured like this :
> <bean id ="someService"
> class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean ">
> <property name="target" ref="targetService"/>
> <property name="transactionManager" ref="txManager"/>
> <property name="transactionAttributes">
> ...
> </property>
> </bean>
>
> should i have a service for each tx mrg ?
>
> Thanks in advance!
>
> Trung
>
> 2007/5/22, Chris Lamey <cl...@localmatters.com>:
> 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 <cl...@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
> <te...@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.
> > > > >
> > > > >
> > >
> > >
> >
>
Re: How can I change datasource connect info on the fly w/iBATIS and Spring?
Posted by tran duc trung <du...@gmail.com>.
Hi,
So how do you set a tx mrg for a service. Normally, i have a service
configured like this :
<bean id ="someService" class="
org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="target" ref="targetService"/>
<property name="transactionManager" ref="txManager"/>
<property name="transactionAttributes">
...
</property>
</bean>
should i have a service for each tx mrg ?
Thanks in advance!
Trung
2007/5/22, Chris Lamey <cl...@localmatters.com>:
>
> 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 <cl...@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 <te...@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.
> > > > >
> > > > >
> > >
> > >
> >
>
Re: How can I change datasource connect info on the fly w/iBATIS
and Spring?
Posted by Chris Lamey <cl...@localmatters.com>.
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 <cl...@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 <te...@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.
> > > >
> > > >
> >
> >
>
Re: How can I change datasource connect info on the fly w/iBATIS and Spring?
Posted by tran duc trung <du...@gmail.com>.
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 <cl...@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 <cl...@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 <te...@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.
> > > >
> > > >
> >
> >
>
Re: How can I change datasource connect info on the fly w/iBATIS
and Spring?
Posted by Chris Lamey <cl...@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 <cl...@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 <te...@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.
> > >
> > >
>
>
Re: How can I change datasource connect info on the fly w/iBATIS and Spring?
Posted by tran duc trung <du...@gmail.com>.
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 <cl...@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 <te...@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.
> > >
> > >
>
>
RE: How can I change datasource connect info on the fly w/iBATIS and Spring?
Posted by Kyohyoh Choh <CH...@jp.ibm.com>.
Hello
Thank you for point out the cachemodel. To switch different datasources for
diffrent users and retrieve the data correctly, we don't want to iBATIS to
cache the data, though it maybe have some performance impart.
In the sqlmapconfig.xml, we do not turn the cacheModelsEnabled="false", so
the cacheModelsEnable property will be true as default value. But for
sqlmap.xml, we don't define any cachemodel property, so I think the cache
does not work for our configuration, is it correct? Or we need set
cacheModelsEnabled="false" in the sqlmapconfig.xml too?
Thank you
RE: How can I change datasource connect info on the fly w/iBATIS and Spring?
Posted by Chris Lamey <cl...@localmatters.com>.
Hello,
I am wondering if you are using the cache in iBATIS via the cacheModel attribute in the sqlmap xml? I would think that switching the datasource out from under the SqlMapClient would cause results from the various data sources to get merged into the SqlMapClient's cache. As far as I know, the cache is not segmented by datasource, but I do not know for certain.
Thanks,
Chris
-----Original Message-----
From: Kyohyoh Choh [mailto:CHOH@jp.ibm.com]
Sent: Mon 4/16/2007 9:42 PM
To: user-java@ibatis.apache.org
Subject: Re: How can I change datasource connect info on the fly w/iBATIS and Spring?
Hello
Our application has a similar requirement that need to switch among
multiple datasources dynamicly, although we do not need to create
datasource in fly. We defined the datasources in ApplicationContex.xml,
then using getBean to load the datasource depand on the user's request
parameter and then set the datasource to the DAO's sqlMapClientTemplate
using setDataSource method. Also we need to define DAO as Singleton=false
to keep thread save.
Best Regards
Paul Sanders
<tendancer@gmail.
com> To
user-java@ibatis.apache.org
2007/04/14 06:27 cc
Subject
Please respond to Re: How can I change datasource
user-java@ibatis. connect info on the fly w/iBATIS
apache.org and Spring?
Interesting.... but you are right, our datasource info is not known in
advance though some are stored in a table and fetched at runtime when the
user selects it from a drop down in the browser. And of course they can
create one on the fly, too.
I wonder if the answer is to unwire the datasource from the DAO bean and
inject it by hand in the controller method. I lose the niceness of the
Spring framework for this particular task but I think it should work?
Paul
Chris Lamey wrote:
>
> 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.
>
> 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
>
>
--
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#a9986772
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
Re: How can I change datasource connect info on the fly w/iBATIS and Spring?
Posted by Kyohyoh Choh <CH...@jp.ibm.com>.
Hello
Our application has a similar requirement that need to switch among
multiple datasources dynamicly, although we do not need to create
datasource in fly. We defined the datasources in ApplicationContex.xml,
then using getBean to load the datasource depand on the user's request
parameter and then set the datasource to the DAO's sqlMapClientTemplate
using setDataSource method. Also we need to define DAO as Singleton=false
to keep thread save.
Best Regards
Paul Sanders
<tendancer@gmail.
com> To
user-java@ibatis.apache.org
2007/04/14 06:27 cc
Subject
Please respond to Re: How can I change datasource
user-java@ibatis. connect info on the fly w/iBATIS
apache.org and Spring?
Interesting.... but you are right, our datasource info is not known in
advance though some are stored in a table and fetched at runtime when the
user selects it from a drop down in the browser. And of course they can
create one on the fly, too.
I wonder if the answer is to unwire the datasource from the DAO bean and
inject it by hand in the controller method. I lose the niceness of the
Spring framework for this particular task but I think it should work?
Paul
Chris Lamey wrote:
>
> 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.
>
> 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
>
>
--
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#a9986772
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
Re: How can I change datasource connect info on the fly w/iBATIS
and Spring?
Posted by Paul Sanders <te...@gmail.com>.
Interesting.... but you are right, our datasource info is not known in
advance though some are stored in a table and fetched at runtime when the
user selects it from a drop down in the browser. And of course they can
create one on the fly, too.
I wonder if the answer is to unwire the datasource from the DAO bean and
inject it by hand in the controller method. I lose the niceness of the
Spring framework for this particular task but I think it should work?
Paul
Chris Lamey wrote:
>
> 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.
>
> 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
>
>
--
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#a9986772
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.