Comment configurer Hibernate pour lire/écrire de différentes sources de données?

Un exemple peut être trouvé ici: https://github.com/afedulov/routing-data-source.

Printemps offre une variation de la source de données, appelé AbstractRoutingDatasource. Il peut être utilisé à la place de la norme de la source de données de mise en œuvre et permet un mécanisme pour déterminer le béton de la source de données à utiliser pour chaque opération au moment de l'exécution. Tout ce que vous devez faire est de le prolonger et de fournir une mise en œuvre d'un résumé determineCurrentLookupKey méthode. C'est la place pour mettre en œuvre votre logique personnalisée pour déterminer le béton de la source de données. Objet renvoyé en sert comme d'une recherche de la clé. Il est généralement une Chaîne de caractères ou fr Enum, utilisé comme qualificatif au Printemps de configuration (détails à suivre).

package website.fedulov.routing.RoutingDataSource

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

public class RoutingDataSource extends AbstractRoutingDataSource {
    @Override
    protected Object determineCurrentLookupKey() {
        return DbContextHolder.getDbType();
    }
}

Vous demandez peut-être ce que c'est que DbContextHolder objet et comment faut-il savoir quelle source de données identificateur de retour? Gardez à l'esprit que determineCurrentLookupKey méthode sera appelée à chaque fois que TransactionsManager demande une connexion. Il est important de se rappeler que chaque transaction est "associé" à un thread séparé. Plus précisément, TransactionsManager lie de Connexion pour le thread courant. Par conséquent, afin de répartir les différentes opérations de cibles différentes Sources de données, nous devons nous assurer que chaque thread peut identifier de manière fiable dont la source de données est destinée à être utilisée. Cela fait qu'il est naturel d'utiliser ThreadLocal variables pour la liaison spécifique de la source de données à un Fil, et donc à une Transaction. C'est comment il est fait:

public enum DbType {
   MASTER,
   REPLICA1,
}

public class DbContextHolder {

   private static final ThreadLocal<DbType> contextHolder = new ThreadLocal<DbType>();

   public static void setDbType(DbType dbType) {
       if(dbType == null){
           throw new NullPointerException();
       }
      contextHolder.set(dbType);
   }

   public static DbType getDbType() {
      return (DbType) contextHolder.get();
   }

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

Comme vous le voyez, vous pouvez également utiliser un enum comme la clé et le Printemps sera de prendre soin de la résoudre correctement en fonction du nom. Associés de la source de données de configuration et les clés pourrait ressembler à ceci:

  ....
<bean id="dataSource" class="website.fedulov.routing.RoutingDataSource">
 <property name="targetDataSources">
   <map key-type="com.sabienzia.routing.DbType">
     <entry key="MASTER" value-ref="dataSourceMaster"/>
     <entry key="REPLICA1" value-ref="dataSourceReplica"/>
   </map>
 </property>
 <property name="defaultTargetDataSource" ref="dataSourceMaster"/>
</bean>

<bean id="dataSourceMaster" class="org.apache.commons.dbcp.BasicDataSource">
  <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
  <property name="url" value="${db.master.url}"/>
  <property name="username" value="${db.username}"/>
  <property name="password" value="${db.password}"/>
</bean>
<bean id="dataSourceReplica" class="org.apache.commons.dbcp.BasicDataSource">
  <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
  <property name="url" value="${db.replica.url}"/>
  <property name="username" value="${db.username}"/>
  <property name="password" value="${db.password}"/>
</bean>

À ce stade, vous pourriez trouver vous-même faire quelque chose comme ceci:

@Service
public class BookService {

  private final BookRepository bookRepository;
  private final Mapper               mapper;

  @Inject
  public BookService(BookRepository bookRepository, Mapper mapper) {
    this.bookRepository = bookRepository;
    this.mapper = mapper;
  }

  @Transactional(readOnly = true)
  public Page<BookDTO> getBooks(Pageable p) {
    DbContextHolder.setDbType(DbType.REPLICA1);   //<----- set ThreadLocal DataSource lookup key
                                                  //all connection from here will go to REPLICA1
    Page<Book> booksPage = callActionRepo.findAll(p);
    List<BookDTO> pContent = CollectionMapper.map(mapper, callActionsPage.getContent(), BookDTO.class);
    DbContextHolder.clearDbType();               //<----- clear ThreadLocal setting
    return new PageImpl<BookDTO>(pContent, p, callActionsPage.getTotalElements());
  }

  ...//other methods

Maintenant, nous pouvons le contrôle de source de données qui sera utilisée et suivre les demandes comme il nous plaît. Semble bon!

...Ou est-il? Tout d'abord, ces méthodes statiques pour un magique DbContextHolder vraiment coller. On dirait qu'ils n'appartiennent pas à la logique d'entreprise. Et ils ne le font pas. En plus de ne pas communiquer dans le but, mais ils semblent fragiles et sujettes à l'erreur (comment oublier de nettoyer le dbType). Et si une exception est levée entre le setDbType et cleanDbType? Nous ne pouvons pas l'ignorer. Nous devons être absolument sûr que nous réinitialiser le dbType, sinon Thread retourné pour le pool de threads peut être "cassée" de l'état, lors de l'écriture d'une réplique dans le prochain appel. Nous avons donc besoin de ceci:

  @Transactional(readOnly = true)
  public Page<BookDTO> getBooks(Pageable p) {
    try{
      DbContextHolder.setDbType(DbType.REPLICA1);   //<----- set ThreadLocal DataSource lookup key
                                                    //all connection from here will go to REPLICA1
      Page<Book> booksPage = callActionRepo.findAll(p);
      List<BookDTO> pContent = CollectionMapper.map(mapper, callActionsPage.getContent(), BookDTO.class);
       DbContextHolder.clearDbType();               //<----- clear ThreadLocal setting
    } catch (Exception e){
      throw new RuntimeException(e);
    } finally {
       DbContextHolder.clearDbType();               //<----- make sure ThreadLocal setting is cleared         
    }
    return new PageImpl<BookDTO>(pContent, p, callActionsPage.getTotalElements());
  }

Aïe >_< ! Absolument, cela ne ressemble pas à quelque chose que je voudrais mettre dans chaque lecture seule méthode. Pouvons-nous faire mieux? Bien sûr! Ce modèle de "faire quelque chose au début d'une méthode, puis faire quelque chose à la fin" devrait sonner une cloche. Aspects à la rescousse!

Malheureusement, ce poste a déjà eu trop longue pour couvrir le sujet de la création d'aspects. Vous pouvez suivre les détails de l'utilisation des aspects à l'aide de cette lien.

OriginalL'auteur Alex Fedulov

Vous pouvez créer 2 session usines et hava un BaseDao envelopper les 2 usines(ou les 2 hibernateTemplates si vous les utilisez) et d'utiliser les méthodes get avec sur l'usine et la saveOrUpdate méthodes avec les autres

OriginalL'auteur Liviu T.

Vous pouvez utiliser DDAL pour mettre en œuvre l'écriture du maître de la base de données et la lecture de base de données esclave dans un DefaultDDRDataSource sans modifier votre Daos, et en plus, DDAL à condition de chargement de la balance pour mulit-esclave bases de données. Il ne repose pas sur spring ou hibernate. Il y a un projet de démonstration pour montrer comment l'utiliser: https://github.com/hellojavaer/ddal-demos et la demo1 est juste ce que vous avez décrit la scène.

OriginalL'auteur allen