Gérer la mise en commun des connexions dans l'application web multi-locataires avec Spring, Hibernate et C3P0

vous pouvez choisir entre 3 stratégies différentes qui auront un impact sur le sondage de connexion. Dans tous les cas, vous devez fournir une mise en œuvre de MultiTenantConnectionProvider . La stratégie que vous choisissez aura bien sûr un impact sur votre mise en œuvre.

remarque générale sur MultiTenantConnectionProvider.getAnyConnection()

getAnyConnection() est requis par hibernate pour collecter les métadonnées et configurer le logiciel SessionFactory. Habituellement, dans une architecture multi-locataires, vous disposez d'une base de données (ou schéma) Spéciale/Principale qui n'est utilisée par aucun locataire. C'est une sorte de base de données de modèle (ou schéma). C'est ok si cette méthode renvoie une connexion à cette base de données (ou schéma).

stratégie 1: chaque locataire possède sa propre base de données. (et donc sa propre piscine de connexion)

dans ce cas, chaque locataire a sa propre piscine de connexion gérée par C3PO et vous pouvez fournir un mise en œuvre de MultiTenantConnectionProvider basée sur AbstractMultiTenantConnectionProvider

chaque locataire a son propre C3P0ConnectionProvider , donc tout ce que vous avez à faire dans selectConnectionProvider(tenantIdentifier) est de retourner le bon. Vous pouvez garder une carte pour les mettre en cache et vous pouvez paresseux-initialiser un C3POConnectionProvider avec quelque chose comme:

private ConnectionProvider lazyInit(String tenantIdentifier){
    C3P0ConnectionProvider connectionProvider = new C3P0ConnectionProvider();
    connectionProvider.configure(getC3POProperties(tenantIdentifier));
    return connectionProvider;
}

private Map getC3POProperties(String tenantIdentifier){
    // here you have to get the default hibernate and c3po config properties 
    // from a file or from Spring application context (there are good chances
    // that those default  properties point to the special/master database) 
    // and alter them so that the datasource point to the tenant database
    // i.e. : change the property hibernate.connection.url 
    // (and any other tenant specific property in your architecture like :
    //     hibernate.connection.username=tenantIdentifier
    //     hibernate.connection.password=...
    //     ...) 
}

stratégie 2 : chaque locataire avoir son propre schéma et son propre pool de connexion dans une seule base de données

ce cas est très similaire à la première stratégie concernant la mise en œuvre de ConnectionProvider car vous pouvez également utiliser AbstractMultiTenantConnectionProvider comme classe de base pour mettre en œuvre votre MultiTenantConnectionProvider

la mise en œuvre est très similaire à la mise en œuvre suggérée pour la stratégie 1 sauf que vous devez modifier le schéma à la place de la base de données dans la configuration c3po

stratégie 3: chaque locataire a son propre schéma dans une seule base de données, mais utiliser un pool de connexion partagée

ce cas est légèrement différent puisque chaque locataire utilisera le même fournisseur de connexion (et donc le pool de connexion sera partagé). Dans le cas : le fournisseur de connexion doit définir le schéma d'utilisation avant toute utilisation de la connexion. i.e. vous devez mettre en œuvre MultiTenantConnectionProvider.getConnection(String tenantIdentifier) (c'est à dire l'implémentation par défaut fourni par AbstractMultiTenantConnectionProvider ne fonctionne pas).

avec postgresql vous pouvez le faire avec:

 SET search_path to <schema_name_for_tenant>;

ou en utilisant l'alias

 SET schema <schema_name_for_tenant>;

alors voici à quoi ressemblera votre getConnection(tenant_identifier); :

@Override
public Connection getConnection(String tenantIdentifier) throws SQLException {
    final Connection connection = getAnyConnection();
    try {
        connection.createStatement().execute( "SET search_path TO " + tenanantIdentifier );
    }
    catch ( SQLException e ) {
        throw new HibernateException(
                "Could not alter JDBC connection to specified schema [" +
                        tenantIdentifier + "]",
                e
        );
    }
    return connection;
}

la référence utile est ici (doc officiel)

autre lien utile C3poconnection Provider.java

---

vous pouvez combiner stratégie 1 et stratégie 2 dans votre mise en œuvre. Vous avez juste besoin d'un moyen de trouver les bonnes propriétés de connexion/url de connexion pour le locataire actuel.

---

modifier

je pense que le choix entre la stratégie 2 ou 3 dépend du trafic et le nombre de locataires votre application. Avec des pools de connexion séparés: le nombre de connexions disponibles pour un locataire sera beaucoup plus faible et donc: si pour une raison légitime un locataire a besoin soudainement de nombreuses connexions la performance vue par ce locataire particulier va radicalement diminuer (tandis que l'autre locataire ne sera pas affecté).

d'autre part, avec la stratégie 3, Si pour quelque raison légitime un locataire a soudainement besoin de beaucoup de connexions: la performance vue par chaque locataire diminuera.

en général, je pense que la stratégie 2 est plus flexible et sûre : chaque locataire ne peut pas consommer plus qu'une certaine quantité de connexion (et cette quantité peut être configurée par locataire si vous en avez besoin)