ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lamey <cla...@localmatters.com>
Subject Re: Changing datasource at runtime
Date Tue, 15 Jan 2008 16:46:50 GMT
Spring isn't good at dynamic DataSource stuff, especially new ones that get
created after the Spring context is instantiated.

This item on the FAQ details the solution I came up with for my stuff:


There aren't any issues with caching, but the DataSources must be known at
Spring creation time which I don't think will work for you.

I've been thinking up different ways of doing this so I don't have to rely
on code changes to get a new datasource running, but I haven't spent much
time on it.  It would be much easier to do without Spring, you could just
use iBATIS directly and create sqlmapclients with a properties object to
configure it.  But Spring offers a lot of nice stuff which I don't want to
get rid of...


On 1/15/08 8:57 AM, "Fearghal O Maolcatha" <fearghal.omaolcatha@gmail.com>

> Hi,
> Our project is currently using Ibatis and the Ibatis DAOs. We plan to
> migrate the Ibatis DAOs to Spring DAOs, which seems straightforward enough.
> However we have a new requirement that will necessitate the changing of the
> datasource at runtime. Our application has the notion of projects, with each
> new project created by the user requiring a new database (same DB schema for
> all projects). Any new work within the project will be saved to the newly
> created database. The user can close a project and open an existing one,
> which would require the datasource to be changed. I've had a look at a
> previous thread
> http://www.mail-archive.com/user-java@ibatis.apache.org/msg08475.html which
> addresses a similar issue but the suggested implementation (wrapping the
> datasource being injected into the SqlMapClient) would have implications for
> the Ibatis cache from what I've read previously. We currently don't use the
> Ibatis cache but might have to for performance reasons in the future.
> Any suggestions on how to proceed with this would be welcome.
> Regards,
> Fearghal.

View raw message