Im Spring-Kontext gilt folgendes: In JPA braucht man pro EntityManagerFactory eine Datasource. Der EMF ist einen TransactionManager zugeordnet.

Man könnte alle Datasource, EMF, TX-Manager und PUs in Spring konfigurieren. Man hat jedoch ein Problem, wenn man n verschiedene Datasourcen hat, die zur Laufzeit ausgewählt werden müssen.

• Die Konfiguration ist umfangreich und unübersichtlich
  • Pro Datasource ist ein Persistence-Unit notwendig, denn für die Ermittlung des richtigen EntityManager kann @PersistenceContext(unitName = “PU_NAME”) verwendet werden
  • Pro Datasource einen EntityManagerFactory mit der Verknüpfung zur PersistenceUnit
  • Pro EntityManagerFactory einen TransactionManager, ggf. mit Qualifier.
• Die Wartung ist entsprechend nicht optimal. Pro neue Datasource müssen 3 Stellen angepasst werden
• Das Transaction-Handling wird kompliziert. @Transactional muss nun immer den richtigen TransactionManager nutzen. Die Entscheidung soll natürlich zur Laufzeit passieren. @Transactional(“TX_MANAGER_NAME”) reicht nicht aus, da es eine statische Kopplung verursacht.

Eine andere Lösungsvariante wäre, statt einen EntityManager durch @PersitenceContext eher direkt den EntityManagerFactory durch @PersistenceUnit zu bekommen. Hier modifiziert man die EntityManager-Erstellung soweit, dass man den EntityManager mit der gewünschten Datasource bekommt. Falls sich bei den Datasourcen nur die User unterscheiden und Eclipselink verwendet wird, siehe u.a. [1].

Perfekt wäre jedoch eine Lösung, in der nur EntityManagerFactory, ein TransactionManager und ein PersistenceUnit verwendet wird. Zur Laufzeit soll dann der vorhandene EntityManagerFactory für die gewünschte Datasource einen EntityManager erstellen.

Das funktioniert. Der EntityManagerFactory erwartet eine Referenz auf die DataSource. Hier könnte man eine eigene Implementierung dieses Interface anbieten, welches die Unterscheidung bzgl. der verschiedenen Datasourcen durchführt. DataSource.getConnection() muss dann abhängig von fest definierten Eigenschaften die Connection von der richtigen Datasource zurückgeben. Um die Eigenschaften in der eigenen DataSource-Implementierung abzufragen, ist die Nutzung von ThreadLocal bzw. InheritableThreadLocal möglich.

Eine Spring-spezifische Lösung die in diese Richtung geht, ist mittels AbstractRoutingDatasource möglich [2]. Hier muss die abstrakte Methode determineCurrentLookupKey() implementiert werden. In dieser Methode muss die Logik verpackt werden, damit anhand des resultierenden Keys die richtige Datasource verwendet werden kann. Das Mapping zwischen Key und Datasource wird in AbstractRoutingDatasources#targetDataSources gehalten. Wird kein Key zurückgeliefert, wird die vorher definierte Standard-Datasource verwendet.

Eine Beispiel-Implementierung, welches mit Spring 3.x und jeweils mit Eclipselink und Hibernate funktioniert, sieht wie folgt aus:

Die relevante Spring-Konfiguration:

<bean id="baseDataSource" abstract="true">
<property name="driverClassName" value="${db.driverClassName}"/>
<property name="url" value="${db.url}"/>
</bean>

<bean id="dataSource1" parent="baseDataSource">
<property name="user" value="${db.1.user}"/>
<property name="password" value="${db.1.pw}"/>
</bean>
<bean id="dataSource2" parent="baseDataSource">
<property name="user" value="${db.2.user}"/>
<property name="password" value="${db.2.pw}"/>
</bean>
<bean id="dataSource3" parent="baseDataSource">
<property name="user" value="${db.3.user}"/>
<property name="password" value="${db.3.pw}"/>
</bean>

<bean id="dynamicDatasource" class="info.center-of.spring.jpa.DynamicDataSourceRouting">
<property name="targetDataSources">
<entry key="${db.1.user}" value-ref="dataSource1"/>
<entry key="${db.2.user}" value-ref="dataSource2"/>
<entry key="${db.3.user}" value-ref="dataSource3"/>
</property>
<property name="defaultTargetDataSource" ref="dataSource1"/>
</bean>

<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalEntityManagerFactoryBean">
<property name="datasource" ref="dynamicDatasource" />
<property name="jpaVendorAdapter">
<!-- Fuer Hibernate -->
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter" p:showSql="true" generateDdl="true" />
<!-- Fuer Eclipselink
<bean class="org.springframework.orm.jpa.vendor.EclipselinkJpaVendorAdapter" p:showSql="true" generateDdl="true" />
-->
</property>
</bean>

<bean class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
</bean>

<tx:annotation-driven />

Die Klasse DynamicDataSourceRouting überschreibt die Methode zur Ermittlung des Keys. In unserem Fall ist dies immer der aktuelle/gewünschte DB-User:

import org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource;

public class CustomerRoutingDataSource extends AbstractRoutingDataSource {

@Override
protected Object determineCurrentLookupKey() {
return DBUserContextHolder.getDBUser();
}
}

DBUserContextHolder ist eine Klasse mit einer ThreadLocal-Variable, die in dem aktuellen Thread den DB-User hält

public class DBUserContextHolder {

private static final InheritableThreadLocal<String> contextHolder = new InheritableThreadLocal<String>();

public static void setDBUser(final String dbUser) {
contextHolder.set(dbUser);
}

public static String getDBUser() {
return (String) contextHolder.get();
}

public static void clear() {
contextHolder.remove();
}
}

Bevor der EntityManager nun erstellt wird, muss

DBUserContextHolder.setDBUser("dbUser1");

aufgerufen werden.

Mit dieser Lösung hat man “nur” eine enge Kopplung mit Spring. Die Lösung funktioniert mit verschiedenen ORMs.

[1]: Wikibook JPA: Provide each application user with a database user id

[2]: Spring Blog: Dynamic DataSource Routing

Technologie
In der Lösung wird nur Spring AOP und Ehcache direkt verwendet. Bei der AOP Implementierung wird nicht AspectJ verwendet um die Anzahl der abhängigen Bibliotheken gering zu halten. Dies ist auch möglich, da die benötigte Funktionalität durch Spring AOP bereitgestellt wird.
Mittels der Spring-Klasse EhCacheManagerFactoryBean wird der Ehcache integriert.

Bibliotheken
In diesem Fall braucht man mindestens (und die entsprechende Abhängigkeiten):

• spring 2.5.6
• ehcache

XML Konfiguration
Die XML Konfiguration für Spring sieht wie folgt aus:

 <!-- ...some other spring configuration... -->

 <!-- Ehcache bean which gets the path the ehcache.xml config file -->
 <bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
        <property name="configLocation" value="classpath:ehcache.xml" />
    </bean>

 <!-- Interceptor which handels the cross cutting concerns (here: caching) -->
 <bean id="coInterceptor" class="de.ic.jee.aop.COCacheInterceptor">
		<constructor-arg index="0" ref="cacheManager" />
  		<!-- Set the name of the cache which will be used from the cache manager -->
		<constructor-arg index="1" value="coCache" />
	</bean>

  <!-- Advisor for the relevant methods -->
    <bean id="coAdvisor" class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
		<property name="advice">
        	<ref local="coInterceptor"/>
		</property>
		<property name="patterns">
                  <!-- only the get and update methods -->
        	  <list>
        		<value>.*update.*</value>
        		<value>.*get.*</value>
        	  </list>
		</property>
	</bean>

  <!-- Proxy factory for aop proxy  -->
	<bean id="coServiceProxy" class="org.springframework.aop.framework.ProxyFactoryBean">
		<property name="target">
                        <!-- The target bean object -->
			<ref bean="coService"/>
		</property>
		<property name="interceptorNames">
			<list>
				<value>coAdvisor</value>
			</list>
		</property>
                <!-- Name of this new generated proxy, to identify this object
                       in the autowired process.
                -->
		<qualifier value="coServiceProxy"/>
	</bean>

Spring AOP ist proxy-basiert. Hierfür wird deswegen ein ProxyFactoryBean definiert, was den Advisor (coAdvisor) auf ein bestimmtes Bean einsetzt, somit entsteht dann eine neue Proxy-Klasse (coServiceProxy).

Mit RegexpMethodPointcutAdvisor kann definiert werden, welche Methoden beobachtet werden. In unserem Fall alle update und get Methoden.

Der Advice bzw. Interceptor (coInterceptor), welcher die Querschnitts-Funktionalität beinhaltet, kriegt eine Referenz auf den CacheManager (hier: cacheManager). Mit dieser Referenz kann beim Methoden-Aufruf vorher im Cache geprüft werden, ob die Antwort schon bekannt ist, wenn nicht, wird die Methode weiter ausgeführt und das Ergebnis (Rückgabewert) dann im Cache gespeichert.

public class COCacheInterceptor implements MethodInterceptor {

    private final CacheManager cacheManager;
    public COCacheInterceptor(final CacheManager cm, final String cn) {
		this.cacheManager = cm;
		this.cacheName = cn;
	}

     public Object invoke(final MethodInvocation methodInvocation) throws Throwable {

          /*
           * Cache cache = cacheManager.getCache(this.cacheName);
           * String cacheKey = .... generate cache key, maybe the arguments of the method invocation
           * get element from the cache
           * Element e = cache.get(cacheKey);
           * If element found:
           * - return e.getObjectValue()
           * otherwise:
           * - proceed the method, methodResult = methodInvocation.proceed()
           * - put the result in the cache, cache.put(new Element(cacheKey, methodResult));
           * - return methodResult;
           */

     } // invoke()
}

Mit wenig Konfiguration und Programmierung kann man sehr einfach Cache-Funktionalität einfügen, ohne die Business Logik zu verändern.

Links:
- Spring AOP: http://static.springsource.org/spring/docs/2.5.x/reference/aop-api.html
- Ehcache: http://ehcache.org/
- Spring 2.5.x API: http://static.springsource.org/spring/docs/2.5.x/api/index.html

In dem Umfeld von Spring kann man Ehcache folgendermaßen integrieren:

Man nutzt das aus dem nicht mehr gewarteten spring-modules-Projekt das cache-Modul. Ja, spring-modules wird durch Spring-Extensions abgelöst, jedoch werden nicht alle Projekte übernommen. D.h. manche Unterprojekte (wohl auch Cache) werden nicht nach Spring-Extensions übernommen. Wo da der Sinn liegt, ist wohl nur den Betreibern klar.

Die aktuelle Version 0.9 findet man auch schon seit Monaten in keinem Maven Repository. Da bleibt nichts anderes übrig, als sich die Bibliothek (spring-modules-cache.jar) selbst in das lokale Repository zu installieren [1]

Für die Abhängigkeit: spring-modules-cache benötigt oro-2.0.8.

Um ein Bean mit Cache-Funktionalität zu erweitern, stellt spring-modules-cache z.B. CacheProxyFactoryBean zur Verfügung um Advices für das Hinzufügen von Objekten (caching advice) und Löschen von Objekte (flushing advice) aus dem Cache bereitzustellen.

<bean id="cacheProviderFacade" class="org.springmodules.cache.provider.ehcache.EhCacheFacade">
        <property name="cacheManager" ref="cacheManager" />
    </bean>

    <bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
        <property name="configLocation" value="classpath:ehcache.xml" />
    </bean>

    <bean id="fCacheableService" class="org.springmodules.cache.interceptor.proxy.CacheProxyFactoryBean">
      <property name="cacheProviderFacade" ref="cacheProviderFacade" />
      <property name="cachingModels">
        <props>
          <prop key="getCodes*">cacheName=fCache</prop>
        </props>
      </property>
      <property name="target" ref="fService" />

      <!-- Set a qualifier to distinguish between the available FServices -->
      <qualifier value="fMain"/>
    </bean>

Wie man in der Konfiguration sehen kann, werden nur die Methoden getCodes* in dem Bean fService ge-cached. Mit dem Qualifier fMain kann man beim Autowiring nun das richtige Bean injizieren, denn durch den CacheProxyFactoryBean gibt es zwei Beans vom gleichen Typ.

Mit wenig Konfiguration hat man jetzt in Spring Caching eingeführt. Dabei wurde der Source-Code gar nicht angefasst – wenn man vom dem nun notwendigen @Qualifier absieht.

Links:
[1] Maven FAQ: Install 3th party library
[2] Spring-Modules: Cache