Zéro arrêt avec Hibernate

Question

Quels sont les changements apportés à une base de données (MySQL dans ce cas) Hibernate survit-il (données, schéma, ...)?

Je pose la question à cause du zéro temps d’arrêt avec Hibernate

Modifiez la base de données, divisez les serveurs d'applications en deux clusters, redéployez l'application sur l'un des clusters et changez d'application.

Merci Stephan

Answer 1

Je vais répondre à cette question par expérience personnelle et non par un aperçu particulier de l'hibernation. Alors prenez ceci avec un grain de sel. Aussi, semble-t-il, poser une question un peu vague, ajouter des commentaires s’il ya lieu. :)

Tout d’abord, modifier / ajouter / supprimer des éléments du schéma qui n’est pas mappé en veille prolongée ne posera jamais de problèmes. Tout ce que hibernate fait vraiment, c’est générer des requêtes, car cela traduit beaucoup de choses en SQL, votre application continuera simplement à fonctionner tant que ces requêtes continueront de fonctionner. Cela signifie que l'ajout de colonnes à une table ou l'ajout de tables n'est pas un problème, la suppression de colonnes que vous n'avez pas mappées n'est pas un problème non plus, etc. etc.

Ce qui est plus problématique, ce sont les modifications apportées aux éléments cartographiés. Supposons que vous changiez un nombre (10,0) en un nombre (11,0), cela fonctionnera généralement. Si vous commencez à faire des choses comme changer un champ CHAR (1) en un champ BIT ou quelque chose de similaire, vous aurez besoin de certains changements dans vos mappages de veille prolongée, ce qui fera échouer un déploiement existant. C'est du bon sens. Si vous devez apporter des modifications de ce type, l’exécution de ALTER TABLE sur un serveur de base de données classique va probablement verrouiller la table de toute façon. Le redémarrage de l’application n’est donc pas votre plus gros problème.

Faire face aux modifications de schéma majeures sous haute disponibilité n’est pas quelque chose que l’hibernation est censée traiter directement. Hibernate suppose une base de données relationnelle traditionnelle dans laquelle les modifications de schéma sont souvent très coûteuses.

Les trois autres problèmes que vous mentionnez:

• modification des sources de données: nécessite probablement un redémarrage de l'application
• partage du serveur d'applications: si vous entendez ce que je pense, vous pouvez simplement le déployer sur différents serveurs d'applications. Si des conversions sont requises, utilisez quelque chose entre votre application Web et le client pour les gérer, c’est-à-dire un équilibreur de charge de niveau IP ou similaire.
• modification des données: les problèmes normaux liés aux bases de données transactionnelles et à plusieurs rédacteurs s'appliquent. Hibernate pourrait se retrouver avec une vue incohérente de la base de données. Cela pourrait écraser les modifications apportées par d’autres utilisateurs et dans certains cas, cela pourrait générer des exceptions, mais vous devriez pouvoir anticiper et agir dans des situations comme celles-ci. AFAICT.