Firebird Embedded

[Jens Hartmann]

Ich denke, das ich mich da an die Vorgaben von Firebird und ZEOS gehalten habe.

Mir geht es momentan nur darum, das ich die ersten Beta Versionen als Testobjekte laufen lassen möchte. Diese Rechner sind reine Einzelrechner und haben auch keinen Netzwerkzugang.

Es geht einfach erstmal um die Programmfunktion.

Die ganze weitere Entwicklung hängt dann sowieso vom Kunden ab. Das ich das Programm entwickelt habe, war Anfangs Spaß an der Freude. Das sich eine Kunde so ernsthaft dafür Interesiert, hätte ich nie gedacht.

Daher ist es erstmal Überhaupt Nebensache mit der Mehrplatzfähigkei, da der Kunde diese Anforderung nicht haben wird.

MFG

Jens

[tsteinmaurer]

Hallo Jens,

wie Andreas erwähnt hat, mußt du aber deine Anwendung auf jeden Fall mehrbenutzerfähig, mit einem gescheiten Transaktionskonzept, usw ... ausrüsten. Ich mach mir hiermit vermutlich keine Freunde, aber von Zeos würde ich mit Firebird lieber die Finger lassen (nichts gegen die Zeos Leute!), aber die fehlende Unterstützung von HARD COMMITs (also nur Soft Commits aka CommitRetaining), ohne hierbei die Connection schließen zu müssen, ist meiner Meinung nach ein NoGo.

[Jens Hartmann]

Hallo tsteinmaurer,

mein Problem zum jetzigen Zeitpunkt ist einfach erklaert. Momentan bin ich in keinem anderen Besitz einer Komponente. Ich habe auch momentan nicht darueber nachdedacht, weil ich zur Zeit noch nicht vor dem Problem stand. Ich habe sicherlich schon von FIBPlus und so gehoert Aber bis lang aus Kostengruenden noch nicht daran gedacht mir diese Komponente zu kaufen.

MFG

Jens

Zitat:

Zitat von tsteinmaurer

Hallo Jens,

wie Andreas erwähnt hat, mußt du aber deine Anwendung auf jeden Fall mehrbenutzerfähig, mit einem gescheiten Transaktionskonzept, usw ... ausrüsten. Ich mach mir hiermit vermutlich keine Freunde, aber von Zeos würde ich mit Firebird lieber die Finger lassen (nichts gegen die Zeos Leute!), aber die fehlende Unterstützung von HARD COMMITs (also nur Soft Commits aka CommitRetaining), ohne hierbei die Connection schließen zu müssen, ist meiner Meinung nach ein NoGo.

[DataCool]

Hi,

kurze Nachfrage, ist es möglich das ein Programm und einen Dienst(teilweise sogar mehrere Connections in Threads) beide auf die Embedded DB zugreifen ?
Denn wenn ich die Aussage über mir richtig deute darf NUR EIN PROZESS(Anzahl der Connections egal) auf die DB zugreifen.

Sehe ich das richtig ?

Greetz Data

[tsteinmaurer]

Hallo,

mit 2.1 und früher ja, mit 2.5 wird sich das ändern. Siehe auch mein FB 2.5 Architektur Comparison Sheet auf meinem Blog: http://blog.upscene.com/thomas/index...y091016-133211

[Chemiker]

Hallo,

Zitat:

Zitat von tsteinmaurer

aber die fehlende Unterstützung von HARD COMMITs (also nur Soft Commits aka CommitRetaining), ohne hierbei die Connection schließen zu müssen, ist meiner Meinung nach ein NoGo.

ich beschäftige mich jetzt schon eine ganze Weile mit der Transaktionssteuerung von Firebird, weil ich eine Anwendung habe die zwar kleine Datensätze in die Datenbank schreibt, dafür sind es am Tag ca. 300.000 Stück. Man kann förmlich zusehen wie der Server langsamer wird. Diese werden mit READ COMMITE abgeschlossen.
Jetzt habe ich irgendwo gelesen, dass bei Interbase(die Open Source Version woraus Firebird entstanden ist) ein READ COMMITE für den Server ständiger Stress bedeutet, angeblich muss dadurch die die Transaction Iventory Page aller Transaktionen jedes Mal neu zusammengestellt werden, wenn ein READ COMMITE verwendet wird.

Bis bald Chemiker

[mkinzler]

Wenn Transaktionen nicht hart commitet werden, leidet die Performance.

[Chemiker]

Hallo mkinzler,

das scheint bei Firebird/Interbase anders zu sein als bei anderen Datenbanken.

Bis bald Chemiker

[mkinzler]

Liegt an der Art und Weise wie Transaktionen implementiert sind. Statt einem Transaktionlog wird Datensatzversionierung verwendet

[hoika]

Hallo,

Zitat:

Jetzt habe ich irgendwo gelesen, dass bei Interbase(die Open Source Version woraus Firebird entstanden ist) ein READ COMMITE für den Server ständiger Stress bedeutet, angeblich muss dadurch die die Transaction Iventory Page aller Transaktionen jedes Mal neu zusammengestellt werden, wenn ein READ COMMITE verwendet wird.

Transaction Iventory Page - TIP

Fast richtig.
Jede neu erzeugte Transaktion bekommt eine Liste der "interessanten" Transaktionen mit,
nennen wir das mal so.
Irgendwann ist jede Transaktion uninteressant,
- wenn die diese erzeugt hat, (hard) committed ist
- es keine früheren Transaktionen mehr gibt
(die diese Trans. in der eigenen TIP haben)
jaja, so einfach ist es nicht, aber lassen wir das mal stehen

Bei einem SoftCommit wird aber die originale TIP kopiert und weiterverwendet.
Sind in der Zwischenzeit einige der sich dort befindlichen Transaktionen "uninteressant",
bleiben die trotzdem drin, wir haben ja kopiert,
statt eine neue TIP zu erzeugen.

das verballert
1. unnötig Speicher
2. muss die viel zu grosse TIP immer wieder (komplett) durchsucht werden

Das war mal vereinfacht.
Unter IBPhoenix.com kann man das sich auch komplizierter erklären lassen ;)
(Stichwort MGA, Multi Generation Architecture)

Die ZEOS nur SoftCommits kann (neue Version ist gerade raus, wie sieht es damit aus ???),
wird der Server mit der Zeit immer langsamer.
Es hilft dann nur ein Beenden aller Anwendungen (Disconnect/Connect reicht).
Abhilfe bei ZEOS ist z.B. bei jedem Form ein neues Connect zu machen.


Heiko