Firebird + php 7: Bug im connect

Forum für Fragen rund um Firebird-Software von Drittanbietern.

Moderator: martin.koeditz

Antworten
vr2
Beiträge: 16
Registriert: Fr 13. Apr 2018, 00:13

Fr 11. Jan 2019, 01:26

Hallo,

seit Ende 2018 ist ja php 5 Geschichte und wer es noch nicht getan hat, muss jetzt auf php 7 umstellen. Leider gibt es im native Firebird-Treiber von php einen üblen Bug ausgerechnet in der connect-Funktion ibase_connect https://bugs.php.net/bug.php?id=72175, der dazu führt, dass bereits geöffnete Connections zur gleichen Datenbank geschrotet werden. Das lässt sich reproduzieren mit Code wie

Code: Alles auswählen

// 1.
$conn = ibase_connect($alias, $usr, $pw, $charset, 0, 3, $role);
$conn2 = ibase_connect($alias, $usr, $pw, $charset, 0, 3, $role);
// $conn ist jetzt ungültig!

// 2.
$conn = ibase_connect($alias, $usr, $pw, $charset, 0, 3, $role);
do_some_admin_task();
// $conn ist jetzt ungültig. Und obwohl das zweite connect 
// sogar in einem anderen scope stattfand
// und in einer anderen Variable den link unterbringt!

function do_some_admin_task () {
   // Als admin zur gleichen DB connecten, zb, um mon$-Tabellen abzufragen
   ...
   $conn2 = ibase_connect($alias, $admusr, $admpw, $charset, 0, 3, $role);
}
Bis php 5.6 lief sowas problemlos. Wer das nie macht oder braucht, ist natürlich nicht betroffen. Aber es ist schon eine deutliche Einschränkung der Nutzbarkeit der Datenbank, wenn man in einem php-Skript nur noch eine Verbindung zu einer DB aufmachen kann, und obendrein quer über alle scopes.

Ist jemand von euch auch davon betroffen? Als halbgaren workaround habe ich in der databases.conf einen weiteren Alias auf die selbe DB angelegt, aber das skaliert natürlich nicht.

Im Moment scheint es wohl daran zu hängen, dass es keinen Maintainer für den Firebird-Treiber mehr gibt, die php-Leute hätten den Treiber schon fast rausgeworfen. Ich hab vor kurzem mit der Firebird-Stiftung Kontakt aufgenommen, denn eine Firma, für die ich arbeite, hat etwas Förderung (1000 Euro) für den Bugfix angeboten, evtl falls nötig in einem zweiten Schritt die Umstellung des connects auf die neue Ressourcenverwaltung von php 7. Perspektivisch wärs gut, wenn sich jemand ab und zu um den Treiber kümmern könnte, normalerweise muss man da über lange Zeiträume nicht ran.

Beim Firebird-ODBC-Treiber fährt die Firebird-Stiftung ein solches Modell, da gibt es jemanden, der sich kümmert, und die Firebird-Stiftung unterstützt das. Wärs Delphi, würde ich es selber machen, habe ganz selten den (erstklassigen) native UIB-Delphi-Treiber für Firebird gefixt/erweitert. Aber C kann ich nicht genug, und von php-Interna und dem build eines php-Systems hab ich keine Ahnung.

Kennt ihr jemanden, der sich gut mit C und php und Firebird- (oder allgemein Datenbank-)Treibern auskennt? Und/oder habt ihr die Möglichkeit, dass eure Firmen sich an der Förderung beteiligen?

Es wäre fatal, wenn die aktuelle php-Version nur mit einem buggy Firebird-connect zu haben wäre oder wenn irgendwann der Firebird-Treiber ganz rausfliegt. Firebird über ODBC ist kein vollwertiger Ersatz, weil dort einige Firebird-Besonderheiten nicht umsetzbar sind. Das gleiche gilt für Firebird-pdo.

Was meint ihr?

Grüße, Volker
bfuerchau
Beiträge: 42
Registriert: Mo 7. Mai 2018, 18:09

Fr 11. Jan 2019, 07:45

Vielleicht wäre dies a eine Alternative:
http://php.net/manual/de/class.dotnet.php
Dann könntest du den .Net-Treiber verwenden, der immer noch weiter entwickelt wird.
Ich habe da nur ein Problem mit Connection-Pooling, aber wenn man das abschaltet und ggf. einen eigenen Pool erfindet, funktionieren beliebig viele Verbindungen parallel.

Und welche Spezifika von Firebird benötigst du, die nicht mit ODBC funktionieren?

Nachtrag
Hier gibts wohl auch eine v4-Integration:
http://www.drupalonwindows.com/en/blog/ ... mblies-php
vr2
Beiträge: 16
Registriert: Fr 13. Apr 2018, 00:13

Fr 11. Jan 2019, 13:50

Danke für die Anregungen. dotnet wäre wieder eine andere Umgebung, und nicht spezifisch Firebird, Mehrzwecktreiber gibt es mit odbc und pdo ja schon. Aber nur der native Treiber macht den vollen Firebird-Funktionsumfang zugänglich, an den sind die Anforderungen am höchsten und grundsätzlich brauche ich den auch:

- prepare
- blobs
- service manager

Nur events und commit/rollback retaining nutze ich bisher nicht, und User anlegen/ändern löschen geht auch direkt über SQL, das ist bspw eine weitere Stelle, wo man eine weitere connection mit Adminrechten einsetzt.

Die Funktionen außer connect sind alle ok - wegen einem bug in einer Funktion den besten Firebird-Treiber nicht mehr zu benutzen, ist keine Lösung. Die Entscheidung für die Datenbank einer größeren Anwendung hat einen Grund und der Treiber muss dem entsprechen. Man will nicht ein Jahr später feststellen, dass ein benötigtes DB-Feature über den Treiber nicht nutzbar ist und alles über den Haufen werfen, mit anderem Treiber umsetzen, bis zum nächsten Feature, das dann dort nicht unterstützt wird. Sonst kann man hinten auch SQLite oder MySQL verwenden und da nur defensiv deren Allerweltsfeatures nutzen - so wie viele Webanwendungen noch immer mit Datenbanken umgehen. Die Anforderungen an Webanwendungen sind gestiegen, in diesem Fall wäre ein Firebird-Admintool die Messlatte.

Grüße Volker
Benutzeravatar
martin.koeditz
Beiträge: 51
Registriert: Sa 31. Mär 2018, 14:35

Fr 11. Jan 2019, 16:53

Hallo Volker,

ich schlage mich schon länger mit dem Gedanken herum, mich um den PHP-Treiber zu kümmern, da es hier stagniert und ich mich relativ gut in den betreffenden Bereichen auskenne.
Weißt du wen man hierfür anschreiben muss?

Leider ist die PHP-Community da leider auch etwas richtungsorientiert. Ich habe vor Jahren einige deutsche Übersetzungen in die Online-Hilfe eingepflegt, die bis heute jedoch nicht bestätigt wurden.

Gruß
Martin
Martin Köditz
it & synergy GmbH
bfuerchau
Beiträge: 42
Registriert: Mo 7. Mai 2018, 18:09

Sa 12. Jan 2019, 00:24

Ich arbeite schon länger mit dem native Firebird-ADO.Net-Treiber.
Er enthält alles was du brauchst, also auch Service-Funktionen und ist umfangreicher als der ODBC-Treiber.
Zusammen mit der php_com_dotnet.dll hast du doch Zugriff auf alles.
Einen Versuch ist es allemal Wert.
vr2
Beiträge: 16
Registriert: Fr 13. Apr 2018, 00:13

Sa 12. Jan 2019, 22:28

Hallo Martin,
martin.koeditz hat geschrieben:
Fr 11. Jan 2019, 16:53
ich schlage mich schon länger mit dem Gedanken herum, mich um den PHP-Treiber zu kümmern, da es hier stagniert und ich mich relativ gut in den betreffenden Bereichen auskenne.
Weißt du wen man hierfür anschreiben muss?
Das wär natürlich spitzenmäßig! Ja, Du kannst Helen Borrie anschreiben, mit der hab ich die letzten Wochen deswegen gemailt, die ist auf dem Stand, sucht einen Maintainer, weiß Bescheid wegen der Förderung, hast Du ihre Adresse? Wenn Du sie anmailst, kannst Du mich bitte ins cc nehmen?

Ich denke, man kann das in 2 Schritte aufteilen

1. Der Bugfix selber - existierende connections zur selben DB dürfen nicht geschreddert werden. Das wär im Moment das wichtigste. Es darf also kein close oder delete auf existierende connections gemacht werden, was jetzt den Bug verursacht. Es darf auch nix recycelt werden - das weißt Du ja alles selber. Ob durch den Fix Ressourcen nicht wieder freigegeben werden, ist demgegenüber erstmal zweitrangig, ein php-Skript läuft normalerweise so kurz, dass die vorerst auch bei Skriptende automatisch freigegeben werden können.

2. Umstellung der connect-Funktion auf die neue php7-Ressourcenverwaltung. Ein Kollege meinte dazu, das wär nicht ganz einfach.

Zum Testen der Extension php_interbase.dll stehe ich jederzeit gern zur Verfügung.
martin.koeditz hat geschrieben:
Fr 11. Jan 2019, 16:53
Leider ist die PHP-Community da leider auch etwas richtungsorientiert. Ich habe vor Jahren einige deutsche Übersetzungen in die Online-Hilfe eingepflegt, die bis heute jedoch nicht bestätigt wurden.
Richtungsorientiert? Ich hab mich schon oft gefragt, wieso die Doku der php-Firebird-Funktionen so unvollständig und veraltet ist, hier würde ich mich gern beteiligen, wenn es einen Weg gibt. Hast Du einen Link in die Online-Hilfe oder wie ist da der Ablauf?

Grüße, Volker
Benutzeravatar
martin.koeditz
Beiträge: 51
Registriert: Sa 31. Mär 2018, 14:35

Mo 14. Jan 2019, 11:00

Hallo Volker,

danke für die Infos. Ich werde Helen heute Abend oder morgen kontaktieren und dich in CC nehmen.

Für die PHP-Doku gibt es den PHP Docbook Online-Editor: https://edit.php.net/.
Dort liegen ein paar meiner Anpassungen noch immer unverifiziert vor. Vielleicht reicht es ja, wenn wir unsere Texte gegenseitig checken.

Gruß
Martin
Martin Köditz
it & synergy GmbH
Antworten