7
votes

Utilisation de HSQLDB dans les environnements de production

Je souhaite utiliser HSQLDB dans un environnement de production pour supprimer certaines données en mémoire et pour l'exportation de données à l'aide de fichiers. Quelqu'un a-t-il de l'expérience avec l'utilisation de HSQLDB dans des environnements de production? HSQLDB traite-t-il les ressources du serveur de manière gracieusement et nettoie-t-il des ressources inutilisées correctement?

J'ai vu un poste critique sur ces questions de Red Hat et je me demande si cela tient toujours pour HSQLDB:

http://kbase.redhat.com/faq/docs/doc-15194 < / a>


2 commentaires

Notez que Red Hat (JBoss) utilise HSQL de manière spécifique - en tant que DB par défaut pour son serveur d'applications, qui stocke toutes sortes de choses - par exemple. Les files d'attente JMS, qui, pour de bonnes performances, ont vraiment besoin d'une base de données très optimisée évolutive.


Notez également que l'article a déplacé: Community.jboss.org/wiki/HypsonononicProduction


4 Réponses :


5
votes

J'ai utilisé HSQL à de nombreuses occasions de production (principalement en tant que stockage rapide des fichiers pour préférences complexes) et n'a jamais rencontré aucun problème.


0 commentaires

5
votes

Je ne sais pas sur hsqldb, mais nous utilisons H2 sur même Aucun problème sans problème.


0 commentaires

3
votes

Je peux confirmer certaines des questions énumérées sur la page Red Hat.

Nous avons eu des problèmes en utilisant HSQLDB comme une instance autonome dans un conteneur Tomcat. L'application ne ferait pas l'arrêt et pendre à 100% de la CPU. Il y avait une solution de code, cependant.

Nous avons également eu des problèmes que certaines données ont été perdues après que le serveur ait été tué de force. Je ne pouvais pas reproduire de manière fiable les situations.

J'ai aussi une certaine étrangeté que je ne peux pas commencer plusieurs instances de la même application à l'aide de HSQLDB en même temps.

Vous devez évaluer si un DB de la mémoire autonome, en mémoire est le bon choix. Si la cohérence et l'intégrité sont essentielles, HSQLDB peut ne pas être le bon choix.


0 commentaires

3
votes

Nous avons expérimenté la corruption de la base de données (une base de données entière a été perdue) quelques fois plus d'une année à l'aide de HSQLDB lorsqu'il n'a pas été fermé proprement.


0 commentaires