欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

Spring ProxyFactoryBean 博客分类: Spring SpringEJBPHP.netBlog 

程序员文章站 2024-03-07 12:03:39
...
There are several discussion about swapping objects during runtime. For example, we may have a case where we need to swap databases depending on the configuration settings or runtime variables, such as user info.

For database related, Spring 2.0 added two classes to short-circuit this case, AbstractRoutingDataSource and its subclass. These two classes are suitable when the choices of swappables are known and listable,  i.e., not based on some formula to deduct the  URL.  The references are:

http://blog.interface21.com/main/2007/01/23/dynamic-datasource-routing/

A more general approach using ProxyfactoryBean is discussed in here:

http://blog.arendsen.net/index.php/2005/07/06/spring-instance-management-part-i-pooling/
http://blog.arendsen.net/index.php/2005/07/06/spring-instance-management-part-ii-pooling/

Recently, I have a case in the distributed computing. I have an ejb-based app which has quite a few ejb services running on different machines. The ejb services are located through a standard service locator. If a service A needs another service B, then A has a piece of code using the locator to find B. This piece of code is pretty ugly because:
1. It results about several hundreds on references on the service locator, which is a singleton, like a wild running cat herd.
2. I can't mock service B for testing.
3. The error handling is wild too.

A better solution is to let A depend on B's interface and inject B from somewhere. we could use Spring's SimpleRemoteStatelessSessionProxyFactoryBean class, however, we have a problem with this. The servers where B is setting on are not fixed, we may move the clusters for several reasons. So even Spring's class is out, with the failover feature, which works only on the fixed cluster. This means the setter during startup time sets something that could be expired and can't be used later on. We have to use the service locator to look for B right before we trigger B's method, i.e., we need a real-time setter.

Another problem, we could refresh the service location settings in real-time. Spring is a little bit hard to do this. So I decide to reuse this.

Spring ProxyFactoryBean can be used for runtime configurations:

1. Switch DataSource depending on the runtime user
2. Delay calling setters which works in real time.