php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Entwicklung > PHP Developer Forum
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


PHP Developer Forum Hier habt ihr die Möglichkeit, eure Skriptprobleme mit anderen Anwendern zu diskutieren. Seid so fair und beantwortet auch Fragen von anderen Anwendern. Dieses Forum ist sowohl für ANFÄNGER als auch für PHP-Profis! Fragen zu Laravel, YII oder anderen PHP-Frameworks.

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #1 (permalink)  
Alt 15-06-2009, 22:07
deedee
 Registrierter Benutzer
Links : Onlinestatus : deedee ist offline
Registriert seit: Jun 2009
Beiträge: 80
deedee befindet sich auf einem aufstrebenden Ast
Standard session speichermöglichkeiten

hello, habe gleich eine neue Frage

Hatte ja schon das Thema "unlink - Fehlerursache" aufgemacht. Das hatte ich aufgemacht, weil ich bei einem eigenen Session-Handler auf dieses Problem gestoßen bin. Dieses Thema ist so eine Art Fortsetzung von dem anderen Thema.

Mein aktueller Session-Handler arbeitet mit Dateien. Damit keine race-conditions stören, mache ich vor dem session_start immer einen LOCK auf eine Dummy-Datei. Das ist natürlich gar nicht toll. Bremst eine Webseite sicherlich ziemlich aus. Darum suche ich jetzt eine Alternative.

Auf PHP: Hypertext Preprocessor sieht man oft Session-Handler mit MySQL-Datenbank. Jetzt überlege ich, ob das die beste Lösung ist. Soviel ich weiß, kann man in MySQL Tabellen vom Typ MEMORY anlegen. Dazu ein paar Fragen:

1) Wenn ich das richtig verstanden habe, legt man in MySQL die Tabelle an, die Daten liegen aber immer nur im RAM. Ist das richtig?
2) Wäre das die optimale Lösung für einen eigenen Session-Handler? Oder könnte ich dann Probleme mit dem Arbeitsspeicher bekommen?
3) Kann man beim Typ MEMORY auch mit LOCK/UNLOCK arbeiten um race-conditions zu verhindern?
4) Kann man bei MEMORY auch zeilenweise LOCKen? Also nicht nur die komplette Tabelle, sondern einen best. Datensatz?

Besonders 1) und 2) interessieren mich. 3) und 4) sollte ich hoffentlich auch noch irgendwie selbst die nächsten Tage herausfinden können. 1) deshalb, weil ich nicht weiß, wie ich kontrollieren kann, woher die Daten kommen, wenn ich einen SELECT mache.? Bei 2) befürchte ich, dass das RAM knapp wird, wenn man z. B. thumbnails erstellen möchte.

Geändert von deedee (15-06-2009 um 22:19 Uhr)
Mit Zitat antworten
  #2 (permalink)  
Alt 15-06-2009, 22:55
wahsaga
  Moderator
Links : Onlinestatus : wahsaga ist offline
Registriert seit: Sep 2001
Beiträge: 25.236
wahsaga befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von deedee Beitrag anzeigen
Mein aktueller Session-Handler arbeitet mit Dateien.
Dein eigener?

Wenn's Dateien sein sollen, warum dann nicht den Default-Mechanismus von PHP nehmen? Der kümmert sich selber ums Locking.

Das "Ausbremsen" minimiert man, in dem man so früh wie möglich die Session wieder schliesst und die Daten wegschreiben lässt.
__________________
I don't believe in rebirth. Actually, I never did in my whole lives.
Mit Zitat antworten
  #3 (permalink)  
Alt 16-06-2009, 09:45
deedee
 Registrierter Benutzer
Links : Onlinestatus : deedee ist offline
Registriert seit: Jun 2009
Beiträge: 80
deedee befindet sich auf einem aufstrebenden Ast
Standard

Es bleibt dann nicht bei diesem eigenen normalen Session-Handler. Da kommen dann noch Sachen in den Session-Handler dazu, damit ich schönes Login-System aufbauen kann. Ist ein Versuch. Vielleicht schmeiß ich das ganze Programm dann auch wieder gleich weg

Das frühzeitige Schließen will ich vermeiden. Bei Programmierfehlern laufe ich Gefahr dann ziemliches Chaos anzurichten, wenn ich dann versehentlich nach dem Schließen noch mit $_SESSION arbeiten sollte.

EDIT:
Habe gerade gelesen, dass row-leve-locking bei MySQL wohl nur bei dem Tabellentyp InnoDB möglich ist. Werde ich es wohl damit machen müssen. Ich schätze, das Thema hat sich dann damit wohl erledigt.

Geändert von deedee (16-06-2009 um 10:33 Uhr)
Mit Zitat antworten
  #4 (permalink)  
Alt 16-06-2009, 10:43
PHP-Desaster
 PHP Expert
Links : Onlinestatus : PHP-Desaster ist offline
Registriert seit: Mar 2006
Beiträge: 3.105
PHP-Desaster befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von deedee Beitrag anzeigen
Bei Programmierfehlern laufe ich Gefahr dann ziemliches Chaos anzurichten, wenn ich dann versehentlich nach dem Schließen noch mit $_SESSION arbeiten sollte.
Ähh, sollte man nicht eher danach streben solches "versehentliches" verwenden zu vermeiden?
Mit Zitat antworten
  #5 (permalink)  
Alt 16-06-2009, 11:59
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard memcache

File Locking dauert dir zu lange, du legst also viel Wert auf Performance.
Andererseits denkst du darüber nach, eine DB für die Daten zu verwenden. Mit der DB redest du SQL, dass du PHP-seitig zusammensetzen musst und das DBS parst es wieder. Das dürfte kaum schneller gehen als ein flock().
Memory Tables bringen dir nichts, da sie auf max_heap_table_size (default 16MB) limitiert sind und der Speicher gelöschter Tupel nicht wiederverwendet werden kann. Bei 10kB/Session könntest du < 2000 Sessions verwalten.
Greif lieber zu memcache. Damit bleiben die Daten auch ständig im RAM, wie bei Memory Tables, aber es gibt keinen Overhead durch SQL oder sonstwas.
Locking gibt es bei memcache nicht, aber du kannst einfach ein Bit setzen.
Mit Zitat antworten
  #6 (permalink)  
Alt 16-06-2009, 12:01
wahsaga
  Moderator
Links : Onlinestatus : wahsaga ist offline
Registriert seit: Sep 2001
Beiträge: 25.236
wahsaga befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von deedee Beitrag anzeigen
Es bleibt dann nicht bei diesem eigenen normalen Session-Handler. Da kommen dann noch Sachen in den Session-Handler dazu, damit ich schönes Login-System aufbauen kann.
Und was reicht dir diesbezüglich an den normalen Möglichkeiten, die dir der Default-Sessionhandler bietet, nicht aus?
__________________
I don't believe in rebirth. Actually, I never did in my whole lives.
Mit Zitat antworten
  #7 (permalink)  
Alt 16-06-2009, 15:51
deedee
 Registrierter Benutzer
Links : Onlinestatus : deedee ist offline
Registriert seit: Jun 2009
Beiträge: 80
deedee befindet sich auf einem aufstrebenden Ast
Standard

Mal schaun, ob ich das in wenigen Worten einigermaßen gut erklären kann. Ist etwas komplex.

Hat sich ein User eingeloggt, kann er über Formulare irgendwelche Sachen eingeben. Zum Login gibt es ein Timeout. War der User zu lange inaktiv, wird er bei seinem nächsten click zur login-Seite umgeleitet, wo er sich wieder neu anmelden muss. Wollte der User gerade eine Datei hochladen, darf die nicht verloren gehen. Nachdem er sich wieder angemeldet hat, sollen die Formulardaten ausgewertet werden. Mein Session-Handling soll sich dann auch um derartige hochgeladene Dateien kümmern. Läuft eine Session aus, soll die GC diese hochgeladenen Dateien löschen.

Wie ich das ganz genau programmieren werden, weiß ich noch nicht.
Mit Zitat antworten
  #8 (permalink)  
Alt 16-06-2009, 15:57
wahsaga
  Moderator
Links : Onlinestatus : wahsaga ist offline
Registriert seit: Sep 2001
Beiträge: 25.236
wahsaga befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von deedee Beitrag anzeigen
Hat sich ein User eingeloggt, kann er über Formulare irgendwelche Sachen eingeben. Zum Login gibt es ein Timeout. War der User zu lange inaktiv, wird er bei seinem nächsten click zur login-Seite umgeleitet, wo er sich wieder neu anmelden muss.
Bei jeder Aktion Timestamp in Session ablegen, bei nächstem Zugriff Differenz zum aktuellen TS ermitteln.

Zitat:
Wollte der User gerade eine Datei hochladen, darf die nicht verloren gehen.
Dann ist sie direkt "beim" Hochladen irgendwo zu sichern.


Zitat:
Mein Session-Handling soll sich dann auch um derartige hochgeladene Dateien kümmern. Läuft eine Session aus, soll die GC diese hochgeladenen Dateien löschen.
Lediglich das erfordert extra Aufwand.

Aber da würde ich eher ein Cronjob-gesteuertes Script einsetzen, das regelmässig zu alte Dateien einfach wegputzt.
__________________
I don't believe in rebirth. Actually, I never did in my whole lives.
Mit Zitat antworten
  #9 (permalink)  
Alt 18-06-2009, 20:13
deedee
 Registrierter Benutzer
Links : Onlinestatus : deedee ist offline
Registriert seit: Jun 2009
Beiträge: 80
deedee befindet sich auf einem aufstrebenden Ast
Standard

Ich komm da mit diesem row-level-locking nicht weiter

Meine open-Funktion ist leer.

In der read-Funktion versuche ich ein row-level-locking. Leider gibts ein Problem, wenn ich vor einem row-level-locking ein table-locking auf eine andere Tabelle versuche. Vereinfach dargestellt:

PHP-Code:
<?php
   
// Hauptprg:
   
error_reporting(E_ALL|E_STRICT);
   include 
'./db.inc.php';              // MySQL
   
$oDb=new MySQL();
   
$oDb->send('set autocommit=0;');     // transaction
   
$oDb->send('LOCK TABLES xy WRITE;'); // table-lock auf beliebige Tabelle
   // ab hier read-Funktion vom Session-Handler:
   
$oDbResult=$oDb->send                // hier kommt eine Fehlermeldung, 
   
(  'SELECT *'.                       // weil session nicht zuvor im LOCK TABLES steht
      
'  FROM session '.
      
'WHERE id=1 '.
      
'FOR UPDATE;'                     // row-lock
   
);
   
$oDb->send('COMMIT;');
?>
Kann man das Problem irgendwie lösen? Ich will nicht beim LOCK TABLES auch die Tabelle session mit aufnehmen. Dann wäre ja das row-level-locking unnütz, oder?

EDIT: eigentlich frage ich mich schon seit Tagen, ob ich so ein Locking beim Session-Handler überhaupt wirklich brauche. Aber angeblich soll man das brauchen ... hat mir mal ein gewisser combie (aus einem anderen Forum) gesagt, wenn ich mich recht erinnere.

EDIT 2: Wäre es besser gewesen, dazu ein eigenes Thema im MySQL-Bereich aufzumachen??

Geändert von deedee (18-06-2009 um 20:38 Uhr)
Mit Zitat antworten
  #10 (permalink)  
Alt 18-06-2009, 20:40
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard

Das war doch bestimmt der selbe combie, der sich auch hier rumtreibt.

Ob du das Locking brauchst, musst du selbst entscheiden. Ich bräuchte es nicht.
Mit Zitat antworten
  #11 (permalink)  
Alt 18-06-2009, 20:46
deedee
 Registrierter Benutzer
Links : Onlinestatus : deedee ist offline
Registriert seit: Jun 2009
Beiträge: 80
deedee befindet sich auf einem aufstrebenden Ast
Standard

Weiß nicht, ob es der gleiche ist. Aber wäre gut. Ich weiß, der kann was

Warum weißt du, dass du es nicht bräuchtest?
Mit Zitat antworten
  #12 (permalink)  
Alt 18-06-2009, 20:49
combie
 PHP Expert
Links : Onlinestatus : combie ist offline
Registriert seit: May 2006
Beiträge: 3.296
combie wird schon bald berühmt werden
Standard

Ob der Combie das war, oder ist, dürfte nicht so wichtig sein....

Aber ohne Sessionlocking rennst du in Richtung "Race Conditions".
1. Willst du das?
2. Schadet dir das?
3. Kannst du das anders abwenden?
__________________
Wir werden alle sterben
Mit Zitat antworten
  #13 (permalink)  
Alt 18-06-2009, 20:58
deedee
 Registrierter Benutzer
Links : Onlinestatus : deedee ist offline
Registriert seit: Jun 2009
Beiträge: 80
deedee befindet sich auf einem aufstrebenden Ast
Standard

1. Willst du das?

2. Schadet dir das?
Ja
3. Kannst du das anders abwenden?
Weiß nicht. Darin bin ich gerade am verzweifeln, wie man row-locking mit table-locking kombinieren kann.
Umgekehrt (zuerst row-locking, dann table-locking) gehts nämlich.
Mit Zitat antworten
  #14 (permalink)  
Alt 18-06-2009, 21:03
combie
 PHP Expert
Links : Onlinestatus : combie ist offline
Registriert seit: May 2006
Beiträge: 3.296
combie wird schon bald berühmt werden
Standard

Falls du mit permanenten DB Verbindungen arbeitest, kannst du dir damit Deadlocks einfangen. Zumindest, wenn das Script mit FatalError abschmiert.
__________________
Wir werden alle sterben
Mit Zitat antworten
  #15 (permalink)  
Alt 18-06-2009, 21:05
deedee
 Registrierter Benutzer
Links : Onlinestatus : deedee ist offline
Registriert seit: Jun 2009
Beiträge: 80
deedee befindet sich auf einem aufstrebenden Ast
Standard

Soweit bin ich noch gar nicht, dass ich jetzt schon an Deadlocks denke. Aber schon mal danke für diesen Tip.

Oder habe ich etwa schon ein Deadlock-Problem, wenn ich versuche, zuerst ein table-lock auf Tabelle a und dann ein row-lock auf Tabelle b zu machen?? Ich dachte, das wäre dann etwas anders.? Momentan arbeite ich aber sowieso nur normal mit mysql_connect.

Geändert von deedee (18-06-2009 um 21:08 Uhr)
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
session automatischer logoff bevor die session ausläuft wirkungsquantum BRAINSTORMING PHP/SQL/HTML/JS/CSS 3 18-04-2007 14:35
IIS6 + WServer 2003 + Session + immer andere Session ID ringintegral Fragen zu Installation & Konfiguration (LAMP, WAMP & Co.) 3 19-10-2005 05:17
Überprüfen ob Session vorhanden, wenn nicht Session anlegen st@tic PHP Developer Forum 28 13-07-2005 13:56
Session & setting session.bug_compat_42 tsaenger PHP Developer Forum 3 24-02-2005 17:14
Smarty, session.use_trans_sid und keine Session-ID im Link mrhappiness PHP Developer Forum 4 09-08-2004 12:34

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni

Wissensbestand in Unternehmen
Wissensbestand in UnternehmenLebenslanges Lernen und Weiterbilden sichert Wissensbestand in Unternehmen

25.05.2018 | Berni


 

Aktuelle PHP Scripte

PHP Server Monitor

PHP Server Monitor ist ein Skript, das prüft, ob Ihre Websites und Server betriebsbereit sind.

11.09.2018 Berni | Kategorie: PHP/ Security
PHP WEB STATISTIK ansehen PHP WEB STATISTIK

Die PHP Web Statistik bietet Ihnen ein einfach zu konfigurierendes Script zur Aufzeichnung und grafischen und textuellen Auswertung der Besuchern Ihrer Webseite. Folgende zeitlichen Module sind verfügbar: Jahr, Monat, Tag, Wochentag, Stunde Folgende son

28.08.2018 phpwebstat | Kategorie: PHP/ Counter
Affilinator - Affilinet XML Produktlisten Skript

Die Affilinator Affilinet XML Edition ist ein vollautomatisches Skript zum einlesen und darstellen der Affili.net (Partnerprogramm Netzwerk) Produktlisten und Produktdaten. Im Grunde gibt der Webmaster seine Affilinet PartnerID ein und hat dann unmittelb

27.08.2018 freefrank@ | Kategorie: PHP/ Partnerprogramme
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 21:56 Uhr.