Embedded DB, die aus mehreren JVMs gestartet werden kann?

[Stinner]

Hallo,
ich arbeite momentan mit Derby in einer Applikation, aber stehe seit Wochen vor einem ungelösten Problem.
Meine Applikation muss später auf einem Netzlaufwerk liegen und mehrere Leute sollen sie öffnen können. Ich habe keinen Server zur Verfügung.
Das Problem ist, dass eine Derby DB in Embedded Mode nur aus einer JVM gestartet werden kann.

Momentan bekommt Person B eine Meldung, dass die Datenbank bereits geöffnet ist, wenn Person A vorher angeklickt hat. Mein Ziel ist es aber, dass Person B, ähnlich wie bei Excel, einfach eine Meldung bekommt, dass er nur im Read-Only öffnen kann.

Zu meiner Frage:
Kennt jmd eine Embedded DB, mit der ich sowas machen könnte bzw. stand jmd mal vor einem ähnlichen Problem.Hier läuft ja gerade eine Umfrage und ich hab mal bei H2 geschaut und da stand auch, dass man eine DB auch nur aus einer JVM starten kann. Gibt es eine Lösung ohne einen Server?
Was könnte ich tun?
Daten über files selbst verwalten ist eine Option, aber dann verliere ich alle Vorteile eines DBMS, bzw. müsste alles selbst machen.

Vielen Dank für Antworten,
Gruß

 

[maki]

Gibt es eine Lösung ohne einen Server?

Nein, nicht wirklich.

Was könnte ich tun?

Einen Server bereitstellen, was ist denn daran das Problem?

 

[Stinner]

Kann ich nicht wirklich beantworten.
Ist kein privates Projekt.
Als ich hier in der Firma gefragt habe, ob es möglich sei einen Server zu bekommen, wurde mir geantwortet, dass es hier per Definition keine Server gibt.

Ich habe also nur das Netzlaufwerk.
Ich versuche momentan rauszufinden, wie Derby die DB sperrt. Über die file "db.lck" geschieht es nicht (nur?). dann könnte ich das evtl umgehen...

 

[maki]

dann könnte ich das evtl umgehen...

Kannst du nicht, was du willst geht einfach nicht.
Oder dachtest du Derby sperrt die DB zum Spass? Datenkonsistenz...

Brauchst einen Server, Definition: Derby als Server starten, fertig. Die Maschine von dem Derby aus gestartet wurde ist dann der Server.

 

[tfa]

Als ich hier in der Firma gefragt habe, ob es möglich sei einen Server zu bekommen, wurde mir geantwortet, dass es hier per Definition keine Server gibt.

Das ist doch ganz einfach. Du nimmst einen Client, packst Linux drauf und lässt ihn 24h/Tag laufen. Fertig ist der Server. Ich mach hier sowas andauernd
Wenn möglich, besorgst du noch eine USV.

Ich habe also nur das Netzlaufwerk.
Ich versuche momentan rauszufinden, wie Derby die DB sperrt. Über die file "db.lck" geschieht es nicht (nur?). dann könnte ich das evtl umgehen...

Wenn du willst, dass die DB funktioniert, solltest du nicht mit sowas rumspielen.

 

[robertpic71]

Eine Lösung ala Excel sollte man schon hinbekommen. Ich kann Weg allerdings nur für H2 beschreiben:
1.) Öffnen mit File-Modus und Sperre
Ok --> Sperrdaten (User/IP) schreiben
Nicht Ok --> Datei mit Read-Only und File-Lock NO öffnen, Hinweis an den Sachbearbeiter, keine Updates "anbieten"

2.) Variante 2 wäre, dass der erste der sich anmeldet auch den TCP-Dienst für die anderen startet und "warnt" wenn sich der Benutzer abmelden will, wenn noch andere Benutzer angemeldet sind. Die Daten dafür bekommt man möglicherweise von H2, sonst muss man selber mitprotokollieren.

3.) Variante 3: Es gibt unterschiedliche Startmöglichkeiten für das Programm: Als Server oder als Client. Der Client könnte die DB wieder mit Read-Only lesen und die IP des aktuellen Servers ermitteln.

Alles keine "ganz schönen" Lösungen - aber immerhin.

/Robert

 

[Stinner]

Also erstmal danke für die Antworten, aber:

+ ich bin hier nur als studentische Aushilfskraft und bin auf Infos der Mitarbeit angewiesen.Habe nach einem Server (sprich zentralen Rechner, auf den jeder Zugriff hat) gefragt und bekam als antwort, dass es hier keinen gibt.

+ derby als server auf einem laptop eines mitarbeiter zu starten kommt nicht in frage, da niemand immer da ist und niemand anderen zugriff auf seinen rechner geben will.

Habe also die Möglichkeit, dass Projekt an dieser Stelle zu beenden oder ich muss halt irgendwie mit den Sperrmechanismen rumspielen bzw. versuchen die zu umgehen.
Außer es gibt evtl eine andere Engine oder eine andere methode?

 

[Stinner]

Eine Lösung ala Excel sollte man schon hinbekommen. Ich kann Weg allerdings nur für H2 beschreiben:
1.) Öffnen mit File-Modus und Sperre
Ok --> Sperrdaten (User/IP) schreiben
Nicht Ok --> Datei mit Read-Only und File-Lock NO öffnen, Hinweis an den Sachbearbeiter, keine Updates "anbieten"

Genauso etwas will ich ja. wenn das mit H2 klappt, dann steige ich um..
Bei derby habe ich das probiert, aber es gibt die option file-lock no nicht. wenn man im read-only modus die DB öffnet, wird sie trotzdem gesperrt, was meiner meinung nach blödsinn ist, dass man das nicht abstellen kann bzw. meines wissens das nicht abstellen kann

 

[maki]

Habe also die Möglichkeit, dass Projekt an dieser Stelle zu beenden oder ich muss halt irgendwie mit den Sperrmechanismen rumspielen bzw. versuchen die zu umgehen.

Solche Dinge regelt man im Vorfeld, jetzt kannst das Projekt an dieser Stelle nur noch beenden.

 

[Stinner]

naja,
wenn das klappt was robert schreibt, gibt es doch eine Lösung...

 

[robertpic71]

Die Steuerung erfolgt über den Connectionstring:

Filelock:
jdbc:h2:<url>;FILE_LOCK=NO;

Read-Only (rws):
...;ACCESS_MODE_LOG=r;ACCESS_MODE_DATA=r

Wobei das 2 verschiedene Einstellungen sind. Also read-only heißt noch nicht, dass es keinen Filelock gibt.

Dein Syntax daher:
jdbc:h2:file:x:/Dir/DBname;FILE_LOCK=NO;ACCESS_MODE_LOG=r;ACCESS_MODE_DATA=r

für den read-only ohne Filelock. Das read-only ist nur zur Sicherheit - falls in der Applikation doch irgendwo ein Update versucht wird.

Der normale Zugriff erfolgt mit:
jdbc:h2:file:x:/Dir/DBname

Wenn er keine Verbindung zustande bringt, kannst du mit der read-only Connection arbeiten bzw. ev. den Sperrer auslesen.

/Robert