Re: 如何在spring框架中解决多数据源的问题

atianchen 写道

当一个请求进来时候，我写了一个Filter会根据request请求信息设置当前的sessionFactory

然后就是重写,需要重写spring关于Hibernate3支持的四个类
HibernateAccessor,HibernateDaoSupport,HibernateTemplate,HibernateTransactionManager
其实主要是修改HibernateAccessor和HibernateTransactionManager的sessionFactory获取方式,由于HibernateDaoSupport->HibernateTemplate->HibernateAccessor,所以重写HibernateAccessor就要重写HibernateDaoSupport和HibernateTemplate

这种方式需要修改 spring，改很多的 spring 类。有一种类似，但是不需修改 spring：
spring 多数据源解决方案

多数据源问题可以打个比喻：假设有个工厂原来可以生产汽车，现在也想这个工厂可以生产火车。
在这个时候，有两个解决办法：
第一种是改造这个工厂的生产设备，使得一个工厂就可以同时生产汽车和火车。
第二种是新建一个工厂，这个工厂专门生产火车。原来的工厂保持不变。

LZ 和 atianchen 用的是第一种方法。还是用一个 BeanFactory ，然后里面声明多个的 DataSource 。用这种方法就需要修改 spring 相关的类。

spring 多数据源解决方案
这里用的就是第二种方法，直接使用多个 BeanFactory ，每个 BeanFactory 使用的 DataSource 不同。使用这种方法，不需修改 spring 的类，而是需要修改上层调用 BeanFactory 的地方。

两种方法的差异在于：
第一种方法使用隐式的参数传递（ThreadLocal，或者SessionContext），希望对上层调用者隐藏多数据源的事实；
第二种方法是直接曝露接口给上层调用者，由调用者决定怎么使用。
如果从灵活性角度来说，第二种会更好。因为调用者可以直接通过 Registry.getBeanFacrtory(xxx).getBean(yyy) 来获得相应的 bean 。对于上面有人提到一次请求中需要用到两个 DataSource 的问题，也可以解决。

由于有 servlet 的 filter 机制，或者 webwork 的 interceptor 机制，所以修改上层调用 BeanFactory 的地方也能够得到很大的简化，并不复杂。