Persistente Verbindung unter Oracle

[DreamDolphin]

Hallo!

Habe da (mal wieder) ein Problem...

Also ich habe bisher nur mit "normalen" Verbindungen unter MySQL und Oracle gearbeitet, die soweit auch gut funktionieren.

Da in meinem Script aber zukünftig einiges an Aufrufen erhalten kann, und es sich somit ständig an der Oracle-DB an- und abmelden würde, wurde mir angeraten, für den Falle einer Überlastung, doch lieber auf eine persistente Verbindung zurückzugreifen...

An sich ja vernünftig, und ich habe auch für MySQL gelesen, dass dieser pconnect zuerst nach einer bereits bestehenden Verbindung sucht, aber leider scheint das für Oracle irgendwie nicht zu funktionieren (ora_plogon)

Beim Aktualisieren der Seite klappt das jedenfalls nur manchmal und beim Wechsel auf eine andere Seite baut er mir grundsätzlich eine neue, weitere persistente Verbindung auf.

Ich habe schon versucht, die Inhalte meiner Variablen $conn und $cursor in eine Textdatei auszulagen (da steht dann sowas wie "resource id #3" oder auch nur "1" drin) und später wieder einzulesen, aber das funktioniert leider nicht.

Gibt es irgendeine Möglichkeit, die Verbindungsvariablen auszulagern, und später wieder auf diese zurückzugreifen?

Vielen Dank schonmal für eure Hilfe.

Gruß
DreamDolphin

[asp2php]

lass die Finger von pconnect. Damit kannst du ganz schnell deine Seite abschiessen, weil die Anzahl der max. zulässigen Verbindungen schnell erreicht werden kann.

btw: und der, der dir das empfohlen hat, kannst du auch auf den Mond abschiessen

[DreamDolphin]

Ja, das merke ich momentan... also zumindest das mit den vielen, bzw. zulässigen Verbindungen. Bin momentan 14 x auf der DB angemeldet Und irgendwann automatisch rausschmeißen ist auch nicht, wahrscheinlich weil der Apache noch läuft...

Der "Ratgeber" war jedenfalls der Meinung, dass z.B. Banken sowas "mit höchster Wahrscheinlichkeit" auch machen würden, da sonst bei soo vielen Zugriffen die DB wohl hops gehen würde... Ich vermute zwar eher, dass die das ganz anders machen, aber egal...


Würde das denn theoretisch überhaupt gehen mit der DB-Variablenauslagerung für verschiedene Seiten? Weil wenn das nicht klappt, dann bin ich... ...fein aus´m Schneider

Gruß
DreamDolphin

[asp2php]

Banken verwenden mit Sicherheit kein MySQL, IMHO meist DB2, Oracle und Sybase. Sie bauen auch keine solche Connection auf, sie arbeiten nur auf Transaktionen, die mit mehreren Sicherheitstufen ausgestattet sind, daß selbst bei Verbindungsunterbrechnung oder Stromausfall eine vernünftige Rollback danach ausgeführt wird, aber das ist ein anderes Thema .

was meinst du mit

Würde das denn theoretisch überhaupt gehen mit der DB-Variablenauslagerung für verschiedene Seiten?

meinst du cachen von den Seiten?

[DreamDolphin]

Ich weiß jetzt nicht, was Du genau mit cachen meinst, aber ich will mal versuchen, das zu verdeutlichen, wie ich mir das vorgestellt hatte...

Also:
Auf der aufgerufen Seite werden die Inhalte meiner Verbindunsvariablen ($conn und $cursor) von irgendwoher geholt (Versuch: Inhalte aus Text-Datei lesen) und auf Gültigkeit/Aktualität überprüft.

Sollte die entsprechende Connection noch offen sein, soll das Script die Variablen einfach weiterverwenden, wenn nicht soll eine neue pers. Verbindung aufgebaut werden. Die entsprechenden neuen (, aktuellen) Werte der beiden Variablen sollen dann wieder weggeschrieben, bzw. ausgelagert werden.

Und wenn man sich durch die Seiten klickt, soll sich das ganze für die Seiten, die eine DB-Verbindung brauchen, wiederholen...

$conn und $cursor sollen also so eine Art globale Variablen für die ganze Webseite sein...


Oder gibt es eine spezielle Art, wie man persistente Verbindungen handeln muß? Wenn ich das für MySQL richtig verstanden habe, ruft man auf den entsprechenden Seiten einfach wieder mysql_pconnect auf, und dann paßt des scho...

Bei ora_plogon hat das leider nicht funktioniert (außer ich habe schnell hintereinander auf Aktualisieren geklickt).

[asp2php]

Hast du den Kapitel: http://de.php.net/manual/en/features...onnections.php schon gelesen? Wenn nicht beachte mal folgendes:

People who aren't thoroughly familiar with the way web servers work and distribute the load may mistake persistent connects for what they're not. [color=red]In particular, they do not give you an ability to open 'user sessions' on the same link[/color], they do not give you an ability to build up a transaction efficiently, and they don't do a whole lot of other things. [color=blue]In fact, to be extremely clear about the subject, persistent connections don't give you any functionality that wasn't possible with their non-persistent brothers.[/color]

und:

The second, and most popular, method is to run PHP as a module in a multiprocess web server, which currently only includes Apache. A multiprocess server typically has one process (the parent) which coordinates a set of processes (its children) who actually do the work of serving up web pages. When a request comes in from a client, it is handed off to one of the children that is not already serving another client. [color=blue]This means that when the same client makes a second request to the server, [/color][color=red]it may be served by a different child process than the first time.[/color] When opening a persistent connection, every following page requesting SQL services can reuse the same established connection to the SQL server.

besonders zu achten ist:

Note, however, that this can have some drawbacks if you are using a database with connection limits that are exceeded by persistent child connections. If your database has a limit of 16 simultaneous connections, and in the course of a busy server session, 17 child threads attempt to connect, one will not be able to. If there are bugs in your scripts which do not allow the connections to shut down (such as infinite loops), the database with only 16 connections may be rapidly swamped. Check your database documentation for information on handling abandoned or idle connections.

bei Oracle mußt du sogar darauf achten, dass du jeder Transaction selbst abschließt, indem du ora_commit absetzst, siehe user contributed notes

ora_plogon
digitalCoffee at zdnetonebox dot com
04-Oct-2000 04:16
When using the persistent login, php obviously does not disconnect, and therefore does not commit any changes you have made to the database. This results in Oracle either locking up, or returning ORA-01554 (Out of transaction slots in transaction tables).

To resolve this, be sure to end your page with ora_commit($connection) (passing in your $connection id).

Wenn du nun vorhast, händisch die Connections zu verwalten, dann mußt du IMHO eigene Funktionen in C schreiben und als Bestandteil von PHP integrieren, wobei du aber immer noch Schwierigkeiten hast, Entscheidungen darüber zu treffen, ob die Request in eine Warteschlange einzureihen, da du NUR eine Verbindung haben willst, oder doch mehrere parallele Verbindungen unterhälst, aber dadurch bist du wieder da wo du jetzt bist . IMHO haben die Entwickler schon gründlich darüber nachgedacht, wenn sie keine andere Lösung anbieten können, dann bedeutet, dass es z.Z. eben keine bessere Möglichkeit gibt.

Außerdem sehe ich bis jetzt immer noch keine sinnvolle Verwendung einer persistente Verbindung zu DBMS bei einer WebApplikation.

[DreamDolphin]

Uff... dass das sooo kompliziert ist, hätte ich dann doch nicht gedacht

Nene, dann lass ich da wirklich lieber die Finger von, bringt ja so nix. (Und würde ich wahrscheinlich eh nicht hinbekommen)

Jedenfalls 1000 Dank! Du hast mir wieder sehr geholfen!