firebird embedded und paralleler Zugriff

[himitsu]

Zitat:

Man braucht keinen Server für multi-Zugriff auf die Firebird 2.5, die embedded kann das genauso gut.
(das ist ja eines der Features, die extra dafür in der 2.5er embedded implementiert wurden)

Und wie wird das mit der Cache gehandhabt?
Oder gleichzeitige Schreibzugriffe, bzw. woher wissen sie ob jemand Anderes was verändert hat usw.

Unterhalten sich dann die Programme miteinander?
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.


Bei einem ReadOnly-Zugriff ist das alles ja kein Problem, aber sonst stell ich mir das eher schwer vor.

[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 )

[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.