2017-07-19 2 views
1

J'ai une application java (jar) installée en tant qu'ensemble OSGI dans Adobe Experience Manager.Le mécanisme de basculement de la connexion DB MyBatis ne fonctionne pas

En application Java je suit la configuration de la source de données: 1. J'utilise mybatis-3 pour gérer les connexions regroupées Datasource en suivant habité: En utilisant les propriétés mentionnées dans http://www.mybatis.org/mybatis-3/getting-started.html

2. Creating SQL Session factory in following manner : 
     SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(configuration); 

3. Using SQL Server 2014 as my database. 

Nous avons un cluster de serveurs DB, chaque fois que nous devons appliquer un correctif à la base de données, nous basculons le serveur DB. Même si l'URL de source de données reste la même, l'application entraîne des erreurs d'échec de connexion à la base de données. Le problème est résolu uniquement après le redémarrage de l'ensemble. Est-il possible que le pool de connexions puisse se reconnecter ou récupérer automatiquement? Je suis nouveau sur MyBatis, SQL server et AEM, toute aide est très appréciée.

+0

Je suppose qu'avec votre approche de secours à froid, toutes les connexions de bases de données déjà ouvertes échoueront. Désolé, je ne connais pas MyBatis. Mais soit vous trouvez une meilleure approche de clustering, soit vous devriez avoir ConnectionPool avec vérification. Cela signifie que le ConnectionPool fait une requête extrêmement simple, avant de distribuer la connexion. Si cela échoue, cette connexion défectueuse est supprimée et une nouvelle est ouverte. Quelqu'un d'autre l'a demandé aussi, mais n'a pas eu de réponse ici: http://mybatis-user.963551.n3.nabble.com/Connection-is-invalid-how-to-check-for-this-and- get-a-valid-connection-td4026961.html –

Répondre

2

La solution de contournement la plus simple pour vous consiste à configurer une requête pool-ping. Il semble que vos connexions ne survivent pas au basculement vers la base de données d'attente à froid. Ils doivent rouvrir. Avec cette requête, le pool de connexions peut vérifier si une connexion est toujours correcte. Sinon, cette connexion défectueuse sera fermée. Après avoir donné mon commentaire, j'ai regardé http://www.mybatis.org/mybatis-3/configuration.html. Il vous devriez chercher les paramètres

  • poolPingQuery
  • poolPingEnabled

J'Essaierait avec la configuration suivante

<dataSource type="POOLED"> 
    ... 
    <property name="poolPingQuery" value="/* ping */ SELECT 1"/> 
    <property name="poolPingEnabled" value="true"/> 
</dataSource> 

Mais il faut savoir, que c'est toujours pas un interrupteur gracieux. Il vérifie uniquement les connexions dans la piscine. Toutes vos transactions en cours recevront toujours une erreur. Mais cela pourrait être bien, si vos transactions sont courtes, pas massivement parallèles, et pas très critique.

+0

Merci pour le délai d'exécution rapide, j'ai lu à propos de poolPingQuery mais je n'ai pas trouvé qu'il peut être utilisé pour rétablir les connexions. Y a-t-il un moyen de basculer gracieusement pour éviter toute erreur pour les sessions utilisateur en cours? – Narendra

+1

Je pense que cela ne fonctionnera pas avec votre cluster de serveurs SQL actif/passif. Vous auriez besoin d'une phase, avec les deux nœuds actifs. Dans cette phase active/active, vous devez basculer gracieusement toutes les connexions. Si le basculement est si important, vous devrez peut-être abandonner le regroupement de connexions. Cela pourrait améliorer certaines choses. Mais la performance va souffrir. –

+0

J'ai regardé les documents du serveur SQL. Il est dit "Lorsqu'un basculement se produit, le nom de réseau virtuel (VNN) est enregistré sur le nouveau nœud actif après son démarrage.Ce processus est transparent ** pour le client ou l'application qui se connecte ** à SQL Server et cela ** minimise le temps d'arrêt ** de l'application ou des clients lors d'une panne. " Donc le fail-over ne fonctionne que pour ** new ** Je crains que vous ne deviez tester avec soin le comportement du cluster SQL, et que le "Select 1" fonctionne, même si le nœud connecté n'est plus actif –