[PHP] Session tijd klopt niet

[g4wx3]

Ik wil de vorige request tijd bijhouden in de php Session.

context:
Deze wil ik gebruiken voor een locking-mechanisme op de databank, die deze tijd vergelijkt met de laatste update. (optimistic locking)
(Is de tijd in databank kleiner: OK->update uitvoeren; is de tijd groter: NOK-> update geweigerd)

Ik maak gebruik van shared hosting bij one.com.
Heb lokaal niet getest

code

PHP:

<?php
session_start();
$microtime = microtime(true);
if(isset($_SESSION['newTime']))
    $_SESSION['oldTime'] = $_SESSION['newTime'];
else
    $_SESSION['oldTime'] = $microtime;
$_SESSION['newTime'] = $microtime;
foreach(array($_SESSION['oldTime'], $_SESSION['newTime']) as $time)
    echo $time."<br>\r\n";
?>

de oude tijd zou de waarde moeten krijgen van de nieuwe tijd in de sessie.
maar dit gebeurt niet, de waard wijkt een beetje af.
Niet onmiddellijk problematisch, maar zou het wel graag oplossen

[Verwijderd]

Even los van het doel van het verhaal: heb je een voorbeeld van de output? je code zou namelijk geen verschil mogen opleveren...

[g4wx3]

Je kan hier de code testen op

tijd uit | tijd in
1496336382.9211|1496336383.6277
1496336384.9389|1496336396.9306
1496336397.3134|1496336402.7141
1496336403.0841|1496336414.4994
1496336414.9827|1496336419.4375
1496336420.7527|1496336438.3529

Zonder in detail te kijken zie je meteen dat de getallen niet hetzelfde zijn


Op mijn persoonlijke testlocatie blijkt het wel te werken zoals het moet:
Men hier kan testen


Dat maakt het raadsel dus alleen maar groter

[ Voor 26% gewijzigd door g4wx3 op 01-06-2017 19:14 ]

[CH4OS]

Hoe werkt het als je time() gebruikt ipv microtime()?
Overigens is er geen verschil in de werking tussen die op de website, als bij jou lokaal?
Vergeet niet, dat je nu steeds de waarde overschrijft in plaats van een waarde toevoegt. Dus de code die je hier in de TS geeft, doet niet hetzelfde als wat je verwacht, denk ik zo.

[ Voor 86% gewijzigd door CH4OS op 01-06-2017 19:19 ]

[_reboot_]

De allereerste keer dat je de pagina opvraagt werkt dit goed. Want $_SESSION['newTime'] is dan nog niet geset.
Iedere keer dat je hierna de pagina herlaadt zal een verschil in tijd opleveren.
De oldTime krijgt namelijk de tijd van newTime vanuit de sessie (die de vorige keer dat je de pagina opvroeg is geset).

Ik zie overigens op beide links hetzelfde gebeuren.

Ah, ik zie nu wat je bedoelt. Kan dit te maken hebben met floating point precisions?
Sla de tijd eens x10000 op of cast hem eens naar een string?

[ Voor 29% gewijzigd door _reboot_ op 01-06-2017 19:23 ]

[HollowGamer]

Gebruik dit a.u.b. niet voor tablelocking, want daar zijn veel betere methodes voor.

[Sendy]

Nu krijg je slechts de eerste keer een frisse sessie; dus meestal (totdat je de cookie deletet) zal je verschillende waarden krijgen. Toch zie ik telkens de onderste waarde naar boven springen bij een refresh, dus werkt het toch gewoon?

[Verwijderd]

g4wx3 schreef op donderdag 1 juni 2017 @ 19:10:
Dat maakt het raadsel dus alleen maar groter

Of anders - bij mij geven beide pagina's de verwachte resultaten.

[g4wx3]

Ik heb zonet gestest met Internet explorer, daar werkt het ook zoals ik het wil.
Dus, een vreemd probleem met chrome??

SessionData wordt toch niet opgeslaan in de cockie?
Ik weet niet meer waar ik het probleem zou moeten zoeken
ik zal als test chrome met proper profiel laden

PS archie2012 Welke methode voor table-locking raad jij aan?

[ Voor 10% gewijzigd door g4wx3 op 01-06-2017 19:35 ]

[Daos]

Misschien doet Chrome meerdere requests. Hou ook eens een tellertje bij.

[Sendy]

Sessiedata staat op je server, maar welke sessiedata je server gebruikt voor mijn sessie staat in een cookie in mijn browser.

[Daos]

In die cookie staat alleen een id. Server gebruikt dat om juiste data op te halen. Wat er in de sessie staat kan de client niet zien.

[Rubenskoo]

Daos schreef op donderdag 1 juni 2017 @ 19:36:
Misschien doet Chrome meerdere requests. Hou ook eens een tellertje bij.

Chrome doet inderdaad meerdere requests: 1 naar de pagina en 1 naar favicon.ico.
Als je die requests opzoekt in de developer tool kloppen de tijden wel:
session.php: 1496339228.0189|1496339278.9709
favicon.ico: 1496339278.9709|1496339279.0723
session.php: 1496339279.0723|1496339338.089
favicon.ico: 1496339338.089|1496339338.1978

[g4wx3]

danku wel, daarmee kan ik het probleem opgelossen

[Voutloos]

Op deze manier in user space een eigen lock algoritme implementeren heeft enkel nut als je houdt van problemen oplossen die je vooral zelf creeert en het dus voor de leerervaring doet.

Als je eigenlijk iets moois wil bouwen maar daar als onderdeel toevallig locking voor nodig hebt, schat ik de kans >99% in dat je iets meer in de richting van wat je OS of DB aanbiedt moet kijken.

[Gomez12]

Even 1 tip : Niet met microtime gaan werken als je geen idee hebt hoe de server-tijd ingesteld staat / hoe die bijgewerkt wordt.

Ik heb geen idee hoe one.com opereert maar wat ik wel van andere budget hosters weet is dat die nog weleens de neiging hebben om de host zwaar te overloaden, waardoor de vm's het niet meer kunnen bijbenen en achter gaan lopen qua tijd, dit is irritant oftewel ze gaan de ntp op de hosts extreem vaak laten draaien en dan heb je feitelijk gewoon een jumpende klok die eigenlijk alleen nog maar een precisie op minuten heeft.