再析在spring框架中解决多数据源的问题.docVIP

在前面我写了《如何在spring框架中解决多数据源的问题》，通过设计模式中的Decorator模式在spring框架中解决多数据源的问题，得到了许多网友的关注。在与网友探讨该问题的过程中，我发现我的方案并不完善，它只解决了一部分问题。 总结多数据源的问题，其实它需要分为以下三种情况：各个数据源的数据结构不同、各个数据源的数据结构相同、各个数据源的数据结构部分相同又有部分不同。对于第二种情况，各个数据源的数据结构相同，我们使用一个sessionFactory，而在sessionFactory中通过MultiDataSource来动态切换数据源，应当是一个不错的方案，既解决了多个sessionFactory对相同的值对象重复装载对内存的浪费，又使数据源的切换对客户程序透明，简化了代码的实现和对客户程序的影响。但是，对于第一种情况，各个数据源的数据结构不同，运用这样的方案存在潜在风险。 对于各个数据源的数据结构不同的情况，使用一个sessionFactory而在这个sessionFactory中动态切换数据源，可能造成数据访问的张冠李戴。譬如，数据源A有表T而数据源B没有，可能造成客户程序在访问表T的时候却尝试去连接数据源B，因为客户程序访问哪个数据源是在程序运行期间由客户程序决定的，因此这样的错误是很难发现的。也许客户程序的一个不经意的错误就可能造成错误。解决这个问题的方法有两个：一是严格要求客户程序不要写错，这当然是可以做到的，但作为框架设计者，另一个解决方法是在框架中就避免出现这样的情况。因此我祭出了MultiSessionFactory的方案来解决各个数据源的数据结构不同的多数据源问题。 问题的分析 与MultiDataSource的方案一样，MultiSessionFactory同样是在spring框架下调用ApplicationContext的getBean()方法而不会另外创建beanFacoty，也同样使用Decorator模式来处理切换的问题。MultiSessionFactory的对象关系如图： 在该方案中，SessionFactory就是Hibernate的org.hibernate.SessionFactory接口，Decorator就是MultiSessionFactory，SessionFactory1和SessionFactory2往往是spring的org.springframework.orm.hibernate3.LocalSessionFactoryBean。细心的朋友可能会注意，实际上LocalSessionFactoryBean并不是SessionFactory的实现，这个方案是否有问题呢？这个问题其实也一直困扰了我好久，最后我发现，我们通过ApplicationContext的getBean()得到一个LocalSessionFactoryBean的时候其实并不是真正地得到了它，而是得到了一个SessionFactory，因为spring为LocalSessionFactoryBean重写了getObject()，使其返回的是SessionFactory。一个简单的明证就是，HibernateDaoSupport的sessionFactory属性的类型是SessionFactory，而我们在spring配置的时候注入的却是LocalSessionFactoryBean。 方案的实现 在整个这个方案中，我们需要实现的只有MultiSessionFactory类和我们可爱的Spserver，总共就两个类，然后呢就是一些spring的配置，就完成了。 MultiSessionFactory实现了SessionFactory，同时为了得到AplicationContext而实现了ApplicationContextAware。MultiSessionFactory的代码如下： java 代码 public?class?MultiSessionFactory?implements?SessionFactory,?ApplicationContextAware?{ ?? ????private?static?final?long?serialVersionUID?=?2064557324203496378L; ?? ????private?static?final?Log?log?=?LogFactory.getLog(MultiSessionFactory.class); ?? ????private?ApplicationContext?applicationContext?=?null; ?? ????private?SessionFactory?sessionFactory?=?n