(temporary) table doesn"t exist

Hallo,
ich fülle eine temp. Table und rufe anschliessend eine andere
PHP-Seite auf, von der ich die Tabelle auslesen möchte, erhalte statt
dessen jedoch die Meldung "table ... doesn't exist".
Dieser Effekt tritt jedoch nur beim ersten Aufruf am Tag auf,
anschliessend läuft alles wunderbar.

Installation:
DB-Server MySQL 4.1.21-community-nt
Web-Server Apache/2.0.58
PHP 4.3.10 läuft als Modul im Apache

Ich habe bereits Restarts von DB-Server und/oder Web-Server versucht,
den Rechner mit dem Browser neu gestartet - der Fehler lässt sich
nicht reproduzieren, er tritt einfach beim ersten Aufruf am Tag auf und
dann nicht mehr an diesem Tag .....

Re: (temporary) table doesn"t exist

"urf" wrote:

> ich fülle eine temp. Table und rufe anschliessend eine andere
> PHP-Seite auf, von der ich die Tabelle auslesen möchte, erhalte statt
> dessen jedoch die Meldung "table ... doesn't exist".
> Dieser Effekt tritt jedoch nur beim ersten Aufruf am Tag auf,
> anschliessend läuft alles wunderbar.

Wenn du die Tabelle mit CREATE TEMPORARY TABLE erzeugst - es also
eine echte temporary table ist - dann ist das ganz normal.

Temporäre Tabellen sind Datenbankobjekte, deren Lebensdauer an die
Datenbankverbindung geknüpft ist. Sobald die Verbindung geschlossen
wird, sind die weg. Außerdem hat jede Verbindung ihren eigenen Namens-
raum. D.h. in jeder Verbindung kannst du eine temporäre Tabelle mit
dem gleichen Namen anlegen. Dann bekommt jede Verbindung ihre eigene
und kann die jeweils anderen nicht sehen.

Normalerweise schließt PHP die Datenbankverbindung, sobald eine Seite
fertig ausgeliefert ist. Wenn du persistente Verbindungen benutzt
(für MySQL *nicht* empfohlen), dann bleibt die Verbindung so lange
bestehen, wie der Apache-Workerprozeß lebt (je nach Konfiguration des
Apachen ein paar Hundert Requests oder auch ewig). Dann funktioniert
deine Methode *scheinbar*. Scheinbar deswegen, weil die Zuordnung von
HTTP-Anfragen an Apache-Workerprozesse (und damit MySQL-Verbindungen)
nicht vorhersagbar ist. Wenn deine erste Abfrage z.B. an Worker 1
geht, dann baut der die temp. Table auf. Anfrage 2 geht aber an
Worker 2, der hat noch keine temp. Table -> Fehler. Ein zufällig vorbei
kommender Nutzer stellt die nächste Anfrage, landet bei Worker 1 und
bekommt "deine" temp. Table. Bullshit.


Was lernen wir: um in Webapplikationen Daten von Seitenaufruf zu
Seitenaufruf weiter zu geben, verwendet man Sessions. Datenbankobjekte
mit Session-Scope (temp. Tables, Uservariablen, LAST_INSERT_ID())
sind dafür grundsätzlich nicht geeignet.


XL

Re: (temporary) table doesn"t exist

nein das ist nicht normal, der Connect wird mit mysql_pconnect (für
persitent) hergestellt. Wenn PHP dann auch noch Apachemodul läuft
hält der Apache die Session auch über mehrere Seiten offen (was er
nach dem ersten Aufruf ja auch macht).

Alles was du unten anführst trifft nur für PHP im CGI-Mode bzw für
normales connect mit PHP als Modul zu.

Axel Schwenke wrote:
> "urf" wrote:
>
> > ich fülle eine temp. Table und rufe anschliessend eine andere
> > PHP-Seite auf, von der ich die Tabelle auslesen möchte, erhalte statt
> > dessen jedoch die Meldung "table ... doesn't exist".
> > Dieser Effekt tritt jedoch nur beim ersten Aufruf am Tag auf,
> > anschliessend läuft alles wunderbar.
>
> Wenn du die Tabelle mit CREATE TEMPORARY TABLE erzeugst - es also
> eine echte temporary table ist - dann ist das ganz normal.
>
> Temporäre Tabellen sind Datenbankobjekte, deren Lebensdauer an die
> Datenbankverbindung geknüpft ist. Sobald die Verbindung geschlossen
> wird, sind die weg. Außerdem hat jede Verbindung ihren eigenen Namens-
> raum. D.h. in jeder Verbindung kannst du eine temporäre Tabelle mit
> dem gleichen Namen anlegen. Dann bekommt jede Verbindung ihre eigene
> und kann die jeweils anderen nicht sehen.
>
> Normalerweise schließt PHP die Datenbankverbindung, sobald eine Seite
> fertig ausgeliefert ist. Wenn du persistente Verbindungen benutzt
> (für MySQL *nicht* empfohlen), dann bleibt die Verbindung so lange
> bestehen, wie der Apache-Workerprozeß lebt (je nach Konfiguration des
> Apachen ein paar Hundert Requests oder auch ewig). Dann funktioniert
> deine Methode *scheinbar*. Scheinbar deswegen, weil die Zuordnung von
> HTTP-Anfragen an Apache-Workerprozesse (und damit MySQL-Verbindungen)
> nicht vorhersagbar ist. Wenn deine erste Abfrage z.B. an Worker 1
> geht, dann baut der die temp. Table auf. Anfrage 2 geht aber an
> Worker 2, der hat noch keine temp. Table -> Fehler. Ein zufällig vorbei
> kommender Nutzer stellt die nächste Anfrage, landet bei Worker 1 und
> bekommt "deine" temp. Table. Bullshit.
>
>
> Was lernen wir: um in Webapplikationen Daten von Seitenaufruf zu
> Seitenaufruf weiter zu geben, verwendet man Sessions. Datenbankobjekte
> mit Session-Scope (temp. Tables, Uservariablen, LAST_INSERT_ID())
> sind dafür grundsätzlich nicht geeignet.
>=20
>=20
> XL

Re: (temporary) table doesn"t exist

Das urf schrieb:

> nein das ist nicht normal

Liebes urf, das *ist* normal. Glaub' es.

> der Connect wird mit mysql_pconnect (für
> persitent) hergestellt. Wenn PHP dann auch noch Apachemodul läuft
> hält der Apache die Session auch über mehrere Seiten offen (was er
> nach dem ersten Aufruf ja auch macht).

*Der* Apache?

Apache ist i.d.R. ein sog. "preforkender" Server. Den will sagen, er
dupliziert sich selbst, so dass viele Leute gleichzeig Webseiten
aufrufen können. D.h. es gibt nicht "einen" Apache-Prozess, sondern
*viele*. Wieviele, das ist in der httpd.conf festgelegt. Jeder dieser
Prozesse hat dann seinen eigenen pconnect und seine eigene temporäre
Tabelle. Wenn Du einen Aufruf (Klick) am Browser machst, dann weisst Du
nicht, bei welchem der Prozesse Du landest - also auch nicht bei welcher
temporären Tabelle.

Wenn die Apache-Prozesse alt sind oder müde, dann beenden sie sich und
werden durch jüngere ersetzt. Auch in diesem Fall ist erst mal keine
temporäre Tabelle da.

Grüße, Matthias

PS: Kauf' Dir mal einen Namen und unterlasse das TOFU. :-)

--
http://www.trullala.de
--
Der Trend geht ganz eindeutig zur Zweitsignatur.

Re: (temporary) table doesn"t exist

Irgendwer oder -was schrieb:

> nein das ist nicht normal, der Connect wird mit mysql_pconnect (für
> persitent) hergestellt. Wenn PHP dann auch noch Apachemodul läuft
> hält der Apache die Session auch über mehrere Seiten offen (was er
> nach dem ersten Aufruf ja auch macht).

Schrieb Axel etwas anderes? Lies sein Posting doch nochmal genau.

Und dann schau bitte noch mal bei http://learn.to/quote vorbei,
und halte Dich zukünftig daran, danke.


Gruß
JPM

Re: (temporary) table doesn"t exist

Du hast es also nicht begriffen.

[TOFU kostenunpflichtig entsorgt]



XL

Re: (temporary) table doesn"t exist

Axel Schwenke wrote:
> Du hast es also nicht begriffen.

doch jetzt ist es klar
hat einen moment zum setzen gebraucht - sorry
Ich hatte das mit dem Session-Handling von Apache falsch verstanden.


Hab trotzdem noch das Problem, wie ich größere Datenmengen von einem
Seitenaufruf zum nächsten persitent rüberbringe.
Die Query in den $_SESSION zu speichern ist nicht das Problem, jedoch
sind die Laufzeiten z.T. recht lang.
Die ganze Tabelle in $_SESSION zu stecken kann bei größeren
Treffermengen (>1000 Zeilen) auch zu Problemen führen.
Hat jemand einen Tipp wie ich das handlen kann ?

Re: (temporary) table doesn"t exist

urf schrieb:
> Hat jemand einen Tipp wie ich das handlen kann ?
z.B. das ganze in deine Datenbank stopfen?
Also die SID als ID und ein Tex feld wo die Daten mit der Funktion
Serializes aufgearbeitet drinn landen.

Das ganze noch mit touch timestamp um hin und wieder mal aufräumen zu
können.

Naja als Tabellen Type HEAP damit alles im RAM liegt, da es sonst einen
0 Effekt haben dürfte.

Und dann beten, das du genug ram hast (-;

Re: (temporary) table doesn"t exist

"urf" wrote:
> Axel Schwenke wrote:

>> Du hast es also nicht begriffen.
> doch jetzt ist es klar

na prima

> Hab trotzdem noch das Problem, wie ich größere Datenmengen von einem
> Seitenaufruf zum nächsten persitent rüberbringe.

Wenn es tatsächlich persistent sein muß, gehört es in die Session.
Wenn es nur darum geht, in einem tabellarischen Ergebnis zu blättern,
sollte man die Query oder - IMHO noch besser - die Suchparameter in
der Session speichern.

> Die Query in den $_SESSION zu speichern ist nicht das Problem, jedoch
> sind die Laufzeiten z.T. recht lang.

Dann solltest du die Query an sich optimieren. Das hat den Vorteil,
daß auch die erste Seite schneller lädt.

Mehr als ca. 1KB Daten in der Session deuten meist (nicht immer) auf
ein falsches Design. So lange man nur einen Webserver hat, kann man
Sessiondaten auf die Platte legen. Da darfs dann auch ein bisschen
mehr sein. Sessiondaten in der Datenbank bilden schnell ein Bottleneck.


XL

Re: (temporary) table doesn"t exist

Axel Schwenke schrieb:
> mehr sein. Sessiondaten in der Datenbank bilden schnell ein Bottleneck.
Sorry, man bekommt was?
Ich kenne diesen Begriff leider nicht.
http://de.wikipedia.org/wiki/Bottleneck

Re: (temporary) table doesn"t exist

"Heiko (GreenRover) Henning" wrote:
> Axel Schwenke schrieb:

>> mehr sein. Sessiondaten in der Datenbank bilden schnell ein Bottleneck.

> Ich kenne diesen Begriff leider nicht.
> http://de.wikipedia.org/wiki/Bottleneck

Das kannte ich noch nicht. Ich meinte eher:

http://de.wikipedia.org/wiki/Flaschenhals_%28Logistik%29


XL

Re: (temporary) table doesn"t exist

Axel Schwenke schrieb:
> http://de.wikipedia.org/wiki/Flaschenhals_%28Logistik%29
Schreib doch einfach deutsch :-ppp

ne aber wiso? dürfte doch wesentlich shcneller gehen in einer HEAP
tabelle die Daten zwischen zu chachen als neu zu selektieren bzw auf der
HDD zu cachen?!

Bzw sowas... http://de.php.net/manual/de/ref.memcache.php es gibt noch
ein besseres Modul, aber mir fällt der Name einfach nicht ein.

PS für Ordnung sorgen ist natür sehr sehr wichtig.

Re: (temporary) table doesn"t exist

"Heiko (GreenRover) Henning" wrote:
> Axel Schwenke schrieb:
>> http://de.wikipedia.org/wiki/Flaschenhals_%28Logistik%29
> Schreib doch einfach deutsch :-ppp
>
> ne aber wiso? dürfte doch wesentlich shcneller gehen in einer HEAP
> tabelle die Daten zwischen zu chachen als neu zu selektieren bzw auf der
> HDD zu cachen?!

Moooment. Es ging um Sessiondaten, die die Zeitspanne zwischen zwei
Seitenaufrufen überleben müssen. Was *genau* das für Daten sind,
spielt erst mal keine große Rolle.

Für die Aufbewahrung dieser Daten hat man im Prinzip drei Möglichkeiten

1. Speicherung lokal im Filesystem des Webservers
2. Speicherung global in einer SQL-Datenbank
3. Speicherung global in einem spezialisierten Daemon (z.B. msession)

Wenn man mehrere Webserver hat und Zugriffe "zufällig" - also nicht
sessionbasiert - verteilt werden, funktioniert 1. natürlich nicht.
3. ist ganz klar das Mittel der Wahl, wenn man ein sehr hohes
Datenaufkommen hat. Andererseits verwendet der Neckermann [1] Online
Shop z.B. MySQL Cluster um Sessiondaten zu speichern.

Auf 2. könnte man verfallen, wenn 1. nicht paßt (mehrere Webserver)
man aber nicht bereit ist, den Aufwand für 3. zu treiben und statt
dessen die ohnehin vorhandene Datenbank nutzen will.

Am besten skaliert Variante 1. weil da mit jedem neuen Webserver auch
gleich der notwendige Sessionspeicher kommt. Außerdem ist lokaler
Speicher immer schneller als über das Netzwerk. Speicherung im
Filesystem verbindet dabei alle Vorteile: der Filesystem-Cache des
Betriebssystems hält die Daten für schnellen Zugriff im RAM. Und wenn
es zuviel Daten werden um sie im RAM zu halten, werden sie vollkommen
transparent auf der Platte gehalten.

Msession, memcached oder MySQL HEAP tables sind zwar schön schnell -
weil sie die Daten im RAM halten - andererseits ist das auch der
Pferdefuß. Wenn denen der Speicher ausgeht, dann geht nix mehr.

Sessiondaten in der SQL Datenbank stellen eine Abwandlung des "Bilder
in der Datenbank" Themas dar. Die Daten sind BLOBs, außerdem noch
kurzlebig und werden ziemlich genau so oft gelesen wie geschrieben.
Für eine SQL-Datenbank keine sehr bekömmliche Workload.


[1] http://www.mysql.com/why-mysql/case-studies/


XL

Re: (temporary) table doesn"t exist

Heiko (GreenRover) Henning schrieb:

> Axel Schwenke schrieb:
>
>> mehr sein. Sessiondaten in der Datenbank bilden schnell ein Bottleneck.
>
> Sorry, man bekommt was?

Einen Flaschenhals.

> Ich kenne diesen Begriff leider nicht.
> http://de.wikipedia.org/wiki/Bottleneck

http://de.wikipedia.org/wiki/Flaschenhals

Gruß. Claus