firebird embedded und paralleler Zugriff

[QuickAndDirty]

Zitat von blackfin:

Zitat:

Geht natürlich nicht unbedingt, wenn die eine Datei auf 'nem Netzlaufwerk nutzen und die Programme keine Verbindung aufbauen können, bzw. sie eh nix voneinander wissen.

Das ist richtig, wenn es verschiedene Hosts sind, braucht man einen Server.
Mehrere Programmzugriffe gleichzeitig auf einem Host geht allerdings, dort gibt es in der FB 2.5 einen globalen, internen Lockmechanismus / Locktable der das regelt.
Zugriffe über ein Netzlaufwerk sind ein "No-Go" beim FB embedded, steht glaube ich sogar im Manual.

Ich wüsste nun aber keine embedded-Datenbank, die concurrent writes ohne manuelles Locking ermöglicht...SQLite kann das ja AFAIK ohne Locking auch nicht.
(allerdings bin ich jetzt auch nicht so der Mensch, der alle embedded-Datenbanken auswendig kennt )

Auf einem Rechner kann das gehen. Was passiert mit den gelockten Datensätzen wenn ein Programm vor dem Unlock abstürzt? Machen die das mit 'nem Haltbarkeitsdatum für ein locking, oder zieht ein Programm dann alle mit in den Tod?

[blackfin]

Gute Frage!! Mal ausprobieren...geht über studieren. Allerdings hatte ich beim FB embedded bei abstürzenden Programmen bisher noch nie Probleme mit Locks.
(und ich habe die Programme schon oft durch Programmfehler in der Entwicklungsphase abstürzen lassen..)

Ich weiss allerdings nicht, wie die das intern machen...leider gibt es da kaum interne Specs, da die Tech-Spezifikationen der Webseite immer noch auf dem Stand der 2.0 sind und auch darauf hingewiesen wird, dass die Dokus etwas hinterherhinken.
(kann gut sein, dass es irgendwo versteckt ist, aber die Seite ist leider eh nicht sonderlich übersichtlich...schade eigentlich, FB ist so eine gute Datenbank..)
Würde mich selbst sehr interessieren, wie die neue Embedded-Superclassic-Architektur des 2.5 intern genau funktioniert.
Beim Client-/Server-Modell ist es ja klar, da ein Prozess alles handeln kann, aber wieso die Embedded so funktioniert wie sie funktioniert, wirft schon Fragen auf

[Lemmy]

guten Morgen,

Zitat von blackfin:

Gute Frage!! Mal ausprobieren...geht über studieren. Allerdings hatte ich beim FB embedded bei abstürzenden Programmen bisher noch nie Probleme mit Locks.

logisch - kanns auch nicht geben, weil Firebird ohne Locks funktioniert und ein komplett anderes Modell verwendet (Multigenerationenarchitektur)

Zitat von blackfin:

Würde mich selbst sehr interessieren, wie die neue Embedded-Superclassic-Architektur des 2.5 intern genau funktioniert.
Beim Client-/Server-Modell ist es ja klar, da ein Prozess alles handeln kann, aber wieso die Embedded so funktioniert wie sie funktioniert, wirft schon Fragen auf

Helen Borrie bereitet gerade die Fortsetzung ihres Buches vor, das sich auch um FB 2.5 kümmern wird. Und ich vermute ganz stark, dass hier auch das Thema ausführlich behandelt wird. Eine "Beta" Version kann bei IBPhoenix.com auf der EntwicklerCD erworben werden. Damit kann man auch die Weiterentwicklung von Firebird finanziell unterstützen.

GRüße

[tsteinmaurer]

Wie es ganz genau funktioniert, das wissen nur die Core-Devs, aber vielleicht reicht dir das: Obwohl Firebird dem MVCC-Modell folgt, verwendet Firebird intern Locks und der "Lock Manager" ist die koordinative Komponente, um gemeinsam benutzte Ressourcen wie Data Pages etc. vor dem gegenseitigen Zugriff zu schützen. So speichert Firebird 2.5 unter Windows z.B. in einem Verzeichnis C:\ProgramData\Firebird sogenannte Lock-Files (Lock-Table), die der Lock-Manager verwaltet. Dadurch ist es auch möglich, dass ein Mischen von Classic/SuperClassic (inkl. Embedded, da auf SuperClassic basierend) für den Zugriff auf eine Datenbank auch schreibend funktioniert. Was man halt nicht machen kann, und was durch eine Fehlermeldung beim Connect von Firebird unterbunden wird ist, ein Mischen von 32 und 64-bit Firebird Prozessen, da sich hier das Layout der Lock-Table unterscheidet.

[himitsu]

Zitat von tsteinmaurer:

So speichert Firebird 2.5 unter Windows z.B. in einem Verzeichnis C:\ProgramData\Firebird sogenannte Lock-Files (Lock-Table),

Toll, daß heißt wenn ich den FBEmbedded in einem portablen Programm verwende, dann mülle ich alle möglichen Systeme zu?
Ich wollte die Embedded doch grade verwenden, damit das nicht passiert.

[Daniel]

Naja, zum Einen räumt FB die Dateien ja bei einem regulären Programm-Ende auch wieder auf und im Endeffekt musst Du Dich halt entscheiden, was Du alles an Funktionalität haben willst. Ich will nicht sagen, dass Du (gefühlt) ständig am Nörgeln bist, aber Du legst eine sehr hohe Messlatte an und ich hoffe, dass Du auch in Deinem eigenen Alltagsgeschäft mit den üblichen Randbedingungen (Zeit etc.) diesem Anspruch ebenfalls gerecht wirst.

[tsteinmaurer]

Es wird auch wieder aufgeräumt.

Ach ja, hatte ich vergessen zu erwähnen: http://dyemanov.blogspot.fr/2012/05/...and-files.html

[himitsu]

Aber auch nur bei "normalem" Programmende ... wer sagt, daß sich mein Programm immer normal beendet?

Na gut, dann hoff ich mal, das räumt auch das Verzeichnis weg.
War ja eher davon ausgegangen, daß es eben nur eine Anwendung pro Datenbankdatei ist ... wer hätte da geglaubt, daß nun doch wieder irgendwas Globales nötig ist.
Aber vielleicht kann man dieses Feature auch einfach deaktivieren?

Schade daß es kein globales Temp-Verzeichnis gibt, denn diese werden regelmäßig automatisch bereinigt. (bei mir privat, was leider nicht überall standardmäßig aktiv ist, und auch auf vielen Servern)
In das C:\Windows\Temp kann nicht jeder reinschreiben und ansonsten hat jeder Benutzer ein Eigenes, wo auch nicht jeder rann kommt.