Comments on: One application, per client database http://blog.deinum.biz/2007/01/05/one-application-per-client-database/ My surface interval on the internet. Fri, 05 Sep 2008 22:39:07 +0000 http://wordpress.org/?v=2.2 By: Cemil http://blog.deinum.biz/2007/01/05/one-application-per-client-database/#comment-2280 Cemil Tue, 06 May 2008 10:43:11 +0000 http://blog.deinum.biz/2007/01/05/one-application-per-client-database/#comment-2280 Hi, Thanks for the article. I implemented some functionality that use HotSwappableTargetSource to switch from multiple datasources . The problem is when user1 goes into application he will use dataSource1 for finding some data .When user2 goes into application he will use dataSource2 to find some data , and I have only swappable target datasource , then when the user1 will try to made a new search he will find the datasource swap to datasource2 which is not good . How can I bound the datasource used from the user session? Or how can i prevent this from occuring by maybe thread/transaction binding the datasource switching ? Any suggestions ? From Cemil Hi,

Thanks for the article.

I implemented some functionality that use HotSwappableTargetSource to switch from multiple datasources . The problem is when user1 goes into application he will use dataSource1 for finding some data .When user2 goes into application he will use dataSource2 to find some data , and I have only swappable target datasource , then when the user1 will try to made a new search he will find the datasource swap to datasource2 which is not good .

How can I bound the datasource used from the user session?

Or how can i prevent this from occuring by maybe thread/transaction binding the datasource switching ?

Any suggestions ?
From Cemil

]]> By: mdeinum http://blog.deinum.biz/2007/01/05/one-application-per-client-database/#comment-1261 mdeinum Fri, 21 Dec 2007 10:01:51 +0000 http://blog.deinum.biz/2007/01/05/one-application-per-client-database/#comment-1261 In the mean time we already changed some of the implemenation to 1 sessionfactory and 'just' 50 datasources, that was the only differences. (We had some increase in clients :) ). Regarding the maintainability that isn´t an issue, all the database are in the same version and use the same version of the application. The other option was to deploy an application per client, that would have been a maintainability issue, managing 50 apps, multiple app servers etc. now we have 1 server serving 50 clients. Very managable. Especially because we only have to create a view, the rest is updated/looked up dynamically. So new view means new client. In the mean time we already changed some of the implemenation to 1 sessionfactory and ‘just’ 50 datasources, that was the only differences. (We had some increase in clients :) ).

Regarding the maintainability that isn´t an issue, all the database are in the same version and use the same version of the application. The other option was to deploy an application per client, that would have been a maintainability issue, managing 50 apps, multiple app servers etc. now we have 1 server serving 50 clients. Very managable.

Especially because we only have to create a view, the rest is updated/looked up dynamically. So new view means new client.

]]> By: al0 http://blog.deinum.biz/2007/01/05/one-application-per-client-database/#comment-1260 al0 Fri, 21 Dec 2007 09:36:18 +0000 http://blog.deinum.biz/2007/01/05/one-application-per-client-database/#comment-1260 Yes, it was not 100% clear from description that they are different DB instances, not just different schemas. But 40 session factories seems terrible expensive to create. BTWmaintability of this solution is as well questionable (what to do if structure for some schemas was updated and for others - not?). Yes, it was not 100% clear from description that they are different DB instances, not just different schemas.
But 40 session factories seems terrible expensive to create.

BTWmaintability of this solution is as well questionable (what to do if structure for some schemas was updated and for others - not?).

]]> By: mdeinum http://blog.deinum.biz/2007/01/05/one-application-per-client-database/#comment-1219 mdeinum Tue, 18 Dec 2007 08:53:50 +0000 http://blog.deinum.biz/2007/01/05/one-application-per-client-database/#comment-1219 @al0 if it was that simple I would have done it but they where also physically different database so on different machines/ports. It wasn't as easy/simple as switching the schema name. @al0 if it was that simple I would have done it but they where also physically different database so on different machines/ports. It wasn’t as easy/simple as switching the schema name.

]]> By: al0 http://blog.deinum.biz/2007/01/05/one-application-per-client-database/#comment-1218 al0 Tue, 18 Dec 2007 08:39:29 +0000 http://blog.deinum.biz/2007/01/05/one-application-per-client-database/#comment-1218 I would possible use much simpler solution - connection customizer (supported by c3p0 that you use anyway AFAIK). And in this customizer issue single SQL-command "set schem DESIRED_SCHEMA" (or, in case of Oracle, "alter session set current_schema=DESIRED_SCHEMA"). Regards, Oleksandr I would possible use much simpler solution - connection customizer (supported by c3p0 that you use anyway AFAIK). And in this customizer issue single SQL-command “set schem DESIRED_SCHEMA” (or, in case of Oracle, “alter session set current_schema=DESIRED_SCHEMA”).

Regards,
Oleksandr

]]>