I tried this approach and it works just fine but as we use Hibernate, the second level hibernate cache did not work. One of the possible solutions to this is to create separate session factory for each data source. But as the session factory object is quite resource demanding and the schema of the data sources were every time the same I tried to find a way around it. In the end we ended up by wrapping CacheProvider and adding our wrapper for the Cache to the system.

The main idea is to prefix cache entries by the data source identificators.

In steps:
1. Implement your AbstractRoutingDataSource and supply it to your Hibernate session factory as described in the blog entry.
2. Implement a wrapper to the CacheProvider which will contain field with CacheProvider implementation supplied from the Spring configuration for instance.
3. The methods of your CacheProvider are just delegating work to the underlying cache provider except for the buildCache method which creates the CacheWrappers:
public Cache buildCache(String name, Properties properties) throws CacheException {
Cache cache = cacheProvider.buildCache(name, properties);
if (!(cache instanceof OKbaseCache)) {
cache = new CacheWrapper(cache, dataSourceProvider);
}
return cache;
}
4. Implement CacheWrapper – it implements interface org.hibernate.cache.Cache and it prefixes the keys of elements which are put/retrieved from the cache by a context based information:
for instance:
public class CacheWrapper implements Cache {

private Cache underlyCache;

public CacheWrapper(Cache underlyCache) {
this.underlyCache = underlyCache;
}

@Override
public void clear() throws CacheException {
underlyCache.clear();
}
….

@Override
public Object get(Object key) throws CacheException {
return underlyCache.get(CustomerContextHolder.getCustomerType() key));
}

Every use of the "key" must be prefixed correspondingly. Of course it might be wise to define your own key which would work with the prefix (data source identification) and the "Object key" and would define correctly hashCode and equals…

In the end you have to inject your CacheProvider into the SessionFactory.

The Hibernate second level cache will work as everytime a user connects to a given data source, he consults the region of cache prefixed with the data source identification, thus objects with same ID from different data sources would not clash.

Note, from Hibernate 3.3 the use of Cache interface is deprecated and we should use RegionFactory instead. But as most caches still work on the base of Cache interface, I guess it can wait to rewrite it to the version using RegionFactory rather than CacheProvider…

But this solution must be uses very carefully in multi-thread context. In SomeBOImpl, a method is exist to below.

public void printAllItems() {
printGoldItems();

printSilverItems();

printBronzeItems();
}

public void printGoldItems() {
CustomerContextHolder.setCustomerType(CustomerType.GOLD);
List goldItems = catalog.getItems();
assertEquals(3, goldItems.size());
System.out.println("gold items: " goldItems);
}

public void printSilverItems() {
CustomerContextHolder.setCustomerType(CustomerType.SILVER);
List silverItems = catalog.getItems();
assertEquals(2, silverItems.size());
System.out.println("silver items: " silverItems);
}

public void printBronzeItems() {
CustomerContextHolder.clearCustomerType();
List bronzeItems = catalog.getItems();
assertEquals(1, bronzeItems.size());
System.out.println("bronze items: " bronzeItems);
}

And two anonymous threads is runned printAllItems() after get SomeBOImpl in spring-context using BeanFactory at almost same time.

Is catalog.getItems() method run correctly as our wish?

Who is ThreadLocal's key? SomeBOImpl? or anonymous thread?

Thax alot, this solve my problem