Je travaille actuellement sur une application (dont la logique et le code ne sont pas disponibles ici) qui crée une base de données derby intégrée et interagit avec elle en utilisant plusieurs threads pour effectuer des opérations CRUD et SELECT .Apache Derby Mode Embarqué et Gestion de Connexion Multi-Thread
Disons que le nom de la base de données intégrée est bar et le chemin vers cette base de données est c: \ foo \ bar
threads multiples ouvrir un leur propre connexion à c: \ foo \ bar et d'effectuer leurs opérations respectives contre leurs propres tables dans la base de données. La connexion à la base de données est extraite par un décorateur qui maintient également la dernière fois que la connexion a été accédée. Si la dernière connexion à la connexion dépasse un certain seuil, la connexion à la base de données est interrompue et récoltée. Il existe un thread de moissonnage qui s'exécute à un intervalle planifié prédéfini et exécute la logique de récolte. En tant que partie de la logique de fauchage, il utilise l'URL d'arrêt suivant:
jdbc:derby:c:\foo\bar;shutdown=true
Tout thread qui tente d'effectuer une requête sur cette base de données après que le fil reaper a exécuté échoue avec l'erreur Derby qui indique qu'il ya pas de connexion en cours.
Ainsi est-ce que dans le mode incorporé de Derby même si chaque thread a ouvert sa propre connexion; lorsque le thread Reaper s'exécute, il ferme la base de données entière et toutes les connexions précédemment ouvertes sur cette base de données sur tous les threads sont maintenant dans un état non valide ou fermé? Quelles sont les meilleures pratiques pour utiliser Derby embarqué dans de telles applications?