Ce que je veux faire: Mon application a une connexion complète avec un Derby DB, et je veux fouiller dans la DB (en lecture seule) en parallèle (à l'aide d'un outil différent). P>
Je ne sais pas comment le derby fonctionne réellement en interne, mais je comprends que je ne peux avoir qu'une connexion active à un DRBY DB. Cependant, étant donné que la base de données consiste uniquement en fichiers sur mon disque dur, je ne pourrai pas pouvoir ouvrir des connexions supplémentaires à celui-ci, en lecture seule? P>
Y a-t-il des outils à faire exactement cela? P>
4 Réponses :
Il y a deux possibilités à exécuter Apache Derby DB. P>
Vous pouvez reconnaître le type à la taille du conducteur. Si le conducteur a plus de 2 Mo de 2 Mo que vous utilisez une version intégrée. P>
Lorsque vous démarrez le moteur derby (serveur ou intégré), il reçoit un accès exclusif aux fichiers de base de données. P>
Si vous devez accéder à une seule base de données à partir de plusieurs machines virtuelles Java (JVM), vous devez mettre une solution de serveur en place. Vous pouvez autoriser des applications à plusieurs JVM qui doivent accéder à cette base de données pour se connecter au serveur. P> blockQuote>
Pour plus de détails, voir Comportement du système à double démarrage . < / p>
C'est intégré. Néanmoins, j'espérais qu'il y aurait un moyen d'ouvrir la DB (en lecture seule) dans une JVM séparée à nouveau. : - /
Avec Derby (et la plupart des autres bases de données), il est techniquement impossible d'obtenir une "vue" en lecture seule unique de la base de données, tandis qu'un autre processus écrit, car le processus d'écriture peut écraser les données («mise à jour en place»).
Deux autres idées: p>
Je réalise que c'est une ancienne question, mais je pensais que je pourrais ajouter un peu plus de détails sur une solution puisque les liens de la réponse actuellement acceptée sont cassés. P>
Il est possible d'exécuter le serveur réseau Derby dans une JVM qui utilise déjà la base de données intégrée. Le code qui utilise la base de données Derby intégrée n'a pas besoin de changer quoi que ce soit et peut continuer à utiliser le DB, mais avec le serveur de réseau Derby, les autres programmes peuvent se connecter à Derby et accéder à la base de données. P>
Tout ce que vous avez à faire est de vous assurer que derbynet.jar est sur le ClassePath P>
Et puis vous pouvez faire l'une des suivantes p>
Inclure la ligne suivante dans le fichier derby.properties: Spécifiez la propriété comme une propriété système au début Java
Vous pouvez utiliser l'API NetworkServerControl pour démarrer le serveur de réseau à partir d'un thread séparé dans une application Java:
Plus de détails ici: http://db.apache.org/ DERBY / DOCS / 10.9 / Administration / TADMINCONFIG814963.HTML P>
Gardez à l'esprit que cela ne permet aucune sécurité à cette connexion, ce n'est donc pas une bonne idée de le faire sur un système de production. Il est possible d'ajouter une sécurité cependant et qui est documenté ici: http: // db.apache.org/ederby/docs/10.9/adminguide/cadminnetservsecurity.html p> derby.drda.startnetworkServer = true code> p> li>
java -dderby.drda.startnetworkserver = true code> p> li>
NetworkServerControl Server = Nouveau NetworkServerControl ();
serveur.start (nouvel imprimeur (System.out)); CODE> P> LI>
ul>
Vous proposez donc une connexion intégrée et une connexion de serveur en même temps. Je ne suis pas sûr que cela soit valide et pourrait conduire à une corruption de données, de db.apache.org/ederby/docs/10.0/manuals/develop/develop79.html - avec une connexion intégrée" Une seule application peut accéder à une base de données à la fois, et une seule application peut accéder à une spécificité Système à la fois. Lors de l'utilisation d'un Pre-1,4 JVM, Derby peut ne pas empêcher de multiples applications d'accéder simultanément au même système Derby, mais ne le permettez pas, car un tel accès peut corrompre les bases de données impliquées. "
Si vous pouvez vous permettre la mémoire et n'avez pas besoin de données à jour, vous pouvez accéder à des bases de données en lecture seule à partir de plusieurs JVM en créant des copies en mémoire: