PHP object opslaan in sessie

[Verwijderd]

Hey

Voor iedereeen me hier begint af te schieten... ik heb wel degelijk de zoekfunctie eerst benut. En veel topics hierover tegengekomen maar toch lukt het mij nog altijd niet.

Mijn code is de volgende. Bedoeling is dus dat die 2 variabelen via de sessie op te halen zijn. Aan de objectdefinities zal het niet liggen want code werkt als ik de variabelen niet uit sessie haal (hoewel ik er dan niet veel mee ben).

code:

require_once('inc/config.php');
require_once('class/MySQL.php');
require_once('class/Basket.php');

session_start(); //voor sessie te starten klassedefinities laden

$db = new MySQL(); //eerst object definieren
if( empty($_SESSION['sess_db']) ) {
    $db->connect($conf_db_host, $conf_db_user, $conf_db_pass, $conf_db_name);
    $_SESSION['sess_db'] = serialize($db);
} else
    $db = unserialize($_SESSION['sess_db']);

$basket = new Basket("",""); //eerst object definieren
if( empty( $_SESSION['sess_basket']) ) {
    if( isset($_SESSION['sess_klantid']) )
        $basket = new Basket($db, $klantid);
    else
        $basket = new Basket($db, "");
    $_SESSION['sess_basket'] = serialize($basket);
} else
    $basket = unserialize($_SESSION['sess_basket']);

merci voor de reacties

edit:

unserialize basket toegevoegd

[ Voor 18% gewijzigd door Verwijderd op 20-09-2005 14:38 ]

[Michali]

Ik zie sowieso dat je sess_basket niet unserialized. (Is serializen en unserializen wel nodig uberhaubt?). Geef verder eens aan wat er nu fout gaat? Krijg je een error?

[ Voor 9% gewijzigd door Michali op 20-09-2005 14:33 ]

[Verwijderd]

Michali schreef op dinsdag 20 september 2005 @ 14:32:
Ik zie sowieso dat je sess_basket niet unserialized. (Is dat wel nodig uberhaubt?). Geef verder eens aan wat er nu fout gaat? Krijg je een error?

das een typefoutje... nee daar ligt het niet aan (ff aangepast).

Fout die ik krijg is is een sql error:

code:

supplied argument is not a valid MySQL-Link resource

Daaruit maak ik dan op dat de klasse er wel is maar alle variabele gereset zijn (daarom dus geen verbinding, geen link)

code db klasse (moet ik nog verder uitwerken mbt foutmeldingen ed)

code:

<?php class MySQL 
{
    var $conn;
    var $result;

    function MySQL() {

    }

    function connect($host, $user, $pass, $db) {
        $this->conn = mysql_connect($host, $user, $pass) or die(mysql_error());
        mysql_select_db($db, $this->conn) or die(mysql_error());
    }

    function query($sql) {
        $this->result = mysql_query($sql,$this->conn) or die(mysql_error());
        return $this->result;
    }

    function disconnect() {
        mysql_free_result($this->result);
        mysql_close($this->conn);
        unset( $_SESSION['sess_db_conn'] );
    }
} ?>

Maar zoals ik al zei werkt alles wel alles ik de variabelen opnieuw aanmaak, aan de klassen zal het dus niet liggen.

[ Voor 11% gewijzigd door Verwijderd op 20-09-2005 14:39 ]

[Michali]

Lijkt me logisch dat je connectie met de db weg is na het eindigen van het script. Je connectie identifier is dus niet meer geldig. Je zult dus eerst opnieuw een connectie moeten maken.

[ Voor 16% gewijzigd door Michali op 20-09-2005 14:39 ]

[Verwijderd]

Michali schreef op dinsdag 20 september 2005 @ 14:39:
Lijkt me logisch dat je connectie met de db weg is na het eindigen van het script. Je connectie identifier is dus niet meer geldig. Je zult dus eerst opnieuw een connectie moeten maken.

Ah ok, ik dacht eigenlijk een db klasse in de sessie bij te houden zodat ik niet telkens opnieuw verbinding moest maken. Gaat dus niet?

[frickY]

volgens mij kun je een link-resource, zoals bijv het resultaat van mysql_connect of fopen, niet in een sessie bewaren.

Some types of data can not be serialized thus stored in sessions. It includes resource variables or objects with circular references (i.e. objects which passes a reference to itself to another object).

Wat je doet is een verwijzing naar een plek in het geheugen onthouden. Maar als die plek in het geheugen later leeg is, heb je daar niets meer aan.

[ Voor 19% gewijzigd door frickY op 20-09-2005 14:42 ]

[Verwijderd]

Ok bedankt voor de snelle reactie allemaal, op elke pagina je connectie opnieuw openen is dus de normale gang van zaken.

[Michali]

Ik zou die MySQL class instance gewoon niet de sessie gooien. Iedere paginarequest een verse instance maken is geen probleem.

edit:
foutje

[ Voor 20% gewijzigd door Michali op 20-09-2005 14:48 ]

[jelmervos]

Verwijderd schreef op dinsdag 20 september 2005 @ 14:43:
Ok bedankt voor de snelle reactie allemaal, op elke pagina je connectie opnieuw openen is dus de normale gang van zaken.

Denk het wel, komt volgens mij doordat HTTP stateless is. Elk request is apart.

[Verwijderd]

Nog even een extra opmerking: je zult nooit een connectie lang open willen houden. Dit lijkt heel simpel bedacht wel het beste voor performance, maar dan maak je een misrekening mbt schaalbaarheid.

Sommige databases hebben een beperking mbt het maximaal aantal connecties dat best laag is, waardoor het aantal gebruikers dat tegelijkertijd op je site is beperkt wordt. Zelfs als er geen harde beperking is aan het aantal openstaande connecties, dan nog zorg iedere openstaande connectie voor een redelijke belasting op je resources, waardoor de load veel te snel oploopt met een groter aantal gebruikers.

Veel databasesystemen en libs die de db's aanspreken zijn in staat tot connection pooling. Als je dan de database connectie sluit in je programma, wordt die niet werkelijk gesloten maar terug in een pool gestopt en voor een volgende nieuwe connectie request gerecycled. Dit zorgt voor een performance die bijna gelijk is aan de connectie openhouden, terwijl de schaalbaarheid veel beter is, zolang je maar weer zo snel mogelijk ook je connectie sluit in je software.

[Verwijderd]

Ik meen dat je met Mysql persistent connections kunt gebruiken. Is dat nou ongeveer wat jij beschrijft MrX? Ik ben niet echt een guru op dit gebied, ik kwam het alleen toevallig net tegen bij een app die ik aan het nabouwen ben uit een boek. Aan het begin van elke pagina wordt de db connectie tot stand gebracht en aan het eind pas weer gesloten. Alle db requests in het tussenliggende gedeelte gebruiken diezelfde db connectie. Dit zou goed zijn voor schaalbaarheid en performance. Het is een beetje een gokje, maar ik denk dat dit voor de TS wel interessant kan zijn.

[drm]

Kaassoevlee:
Denk het wel, komt volgens mij doordat HTTP stateless is. Elk request is apart.

Dat is niet zo zeer afhankelijk van HTTP, maar van hoe de server met de verbindingen om gaat. Zie 't verhaal van MrX.

[Verwijderd]

Ik geloof dat persistent connections inderdaad een soort interne connection pool binnen PHP gebruikt.

quote: http://www.php.net/manual/en/function.mysql-pconnect.php

mysql_pconnect() acts very much like mysql_connect() with two major differences.

First, when connecting, the function would first try to find a (persistent) link that's already open with the same host, username and password. If one is found, an identifier for it will be returned instead of opening a new connection.

Second, the connection to the SQL server will not be closed when the execution of the script ends. Instead, the link will remain open for future use (mysql_close() will not close links established by mysql_pconnect()).

This type of link is therefore called 'persistent'.

[WormLord]

En als je toch connecties in de sessie wil kunnen opslaan, dan moet je eens kijken naar de methods __sleep en __wakeup. Hiermee kun je namelijk nog iets doen net voor de serialize en net na de unserialize. Tenminste, in php 4.

En om een object in de sessie te zetten, hoef je dat zelf niet te serializen. Dat doet php zelf al.

[PrisonerOfPain]

WormLord schreef op dinsdag 20 september 2005 @ 15:20:
Tenminste, in php 4.

Ook onder php5 . Overigens moet je die sowieso implementeren als je een resource bijhoud als member variabele van je class, PHP kan immers niet garanderen dat die nog bestaat bij het unserializen.

[drm]

PHP kan immers niet garanderen dat die nog bestaat bij het unserializen

Sterker nog:

quote: http://www.php.net/serialize

To make the serialized string into a PHP value again, use unserialize(). serialize() handles all types, except the resource-type.

[Verwijderd]

Verwijderd schreef op dinsdag 20 september 2005 @ 15:10:
Ik geloof dat persistent connections inderdaad een soort interne connection pool binnen PHP gebruikt.

Is dit wederom jammerlijke naamgeving van de makers van php of is de connectie werkelijk persistent?

[Verwijderd]

@mark platvoet: wat bedoel je met 'werkelijk persistent'? De functionaliteit is zoals is hierboven ge-kwoot heb, niets meer of minder.

[twiekert]

'Persistent' database connections worden hier uitgelegd wat het wel en wat het niet is:
http://nl3.php.net/manual...ersistent-connections.php

[Janoz]

De beschrijving die daar staat is de omschrijving van een connection pool. Dat heeft dus niks met persistent connections te maken. Bij een persistent connection denk ik eerder aan iets waarbij dezelfde client steeds dezelfde connectie terug krijgt (ie op de ene pagina inserten en op de volgende pagina mysql_insert_id op kunnen vragen).

Als je vervolgens naar de implementatie kijkt blijkt het weer heel anders te zijn. Er wordt niet 'serverwide' een pool bij gehouden, maar per (child)process. Dat betekend dat wanneer appache 20 child porcesses heeft en mysql een maximum aantal van 15 connections heeft je webapplicatie vast loopt wanneer het ene request door het 16e child proces afgehandeld wordt.

Dat alles heeft te maken met de gebrekkige scope implementaties van php.

[ Voor 6% gewijzigd door Janoz op 20-09-2005 23:03 ]

[Verwijderd]

Janoz schreef op dinsdag 20 september 2005 @ 23:02:
[...]
Als je vervolgens naar de implementatie kijkt blijkt het weer heel anders te zijn. Er wordt niet 'serverwide' een pool bij gehouden, maar per (child)process. Dat betekend dat wanneer appache 20 child porcesses heeft en mysql een maximum aantal van 15 connections heeft je webapplicatie vast loopt wanneer het ene request door het 16e child proces afgehandeld wordt.
[...]

Daar was ik inderdaad bang voor. Het voordeel van de oplossing is dat het inProcess is, dus snel, maar dit is dan wel zo'n groot nadeel, dat het de schaalbaarheid zeer beperkt.