Come da titolo,
sto facendo alcuni test sulla gestione custom delle sessioni, quindi non piu' delegando a php tutta le gestione dei dati di sessione ma "registrando" i mei handlers personali.
Dalla 5.4 c'e' una bellissima interfaccia da implementare che fornisce gia' le definizioni dei metodi.
MA nella 5.3 questa non c'e'.

Ho impostato il codice (OVVIAMENTE E' SOLO PER TESTARE!!!) :

1- factory per avviare la registrazione dei metodi della classe al punto 3.
2- interfaccia
3- classe che implementa l'interfaccia

(RIPETO :: e' solo codice di prova per velocità di scrittura del codice per i test, nei vari script posso fare " sessionFactory::registerHandlers() " e ho finito di preoccuparmi.

Cmq per gestire le read/write ho impostato una tabella innoDB con alcune colonne per gestire i dati di session (sessionId,sessionValue,creation,lastEdit,maxLifetime-still unused 4 now) ...

Ora ho implementato la gestione delle read/write "lockando in share mode" prima di eseguire update o altre cose sulla riga interessata. QUindi ho impostato le destroye etc.... funziona tutto anche con chiamate ajax e chiamate concorrenti.

Ora pero' ho 1 dubbio.

Se la sessione scade che succede ?
Gli script di test regitrano il mio codice per gestire la sessione ma a morte dello script ?
Tali handlers non ci sono piu', come faccio a rimuovere la sessione dal db quando l'utente spegne il browser e va pinciare la bambola gonfiabile ?
Pensavo di gestire il garbage collector aggiungendo il contatore di sessioni aperte... ma non so... Se avete qualche idea piu' precisa / migliore sto qua..

Up ...

nessuno ???????

la scadenza implicita delle sessioni è un problema noto e ci sono varie soluzioni che vengono utilizzate... intanto i controlli durante l'utilizzo dovrebbero garantire la consistenza delle sessioni stesse, mentre tipicamente si utilizza un timeout (a volte anche forzato, cioè dopo X minuti la sessione scade anche se l'utente è loggato, ma dipende da che tipo di sistema si sta usando: può essere "pericolosa" questa scelta)

La mia idea sarebbe questa :

1- inserire un contatore di riferimenti
2- re-impostare iil medodo di grabage collection in modo che :
- estrapoli con "lock in share mode" tutte le sessioni con 0 riferimenti
- controlli l'ultima modifica
- se mod superiore a timeout elimina la riga.

In modo che quando parte il gc pulisca le sessioni intattive.
Unitamente al fatto di controllare sempre i timeouts a read della sessione.

Certo che e' comodo registrare gli handlers per poter gestire manualmente le sessioni. E' pazzesco che non posso allocare tali handlers in sessione al primo avvio dell'app e poi lasciarli lavorare per tutti..... ma questo di persistenze e' gestibile in php ? Se si come ?

non ho ben capito cosa vorresti con "allocare gli handlers in sessione"... puoi spiegare meglio questo aspetto?

no fermo persistenza e sessioni sono 2 cose diverse.

Ho lavorato su hibernate su server tomcat e devo dire che la possibilità di usare le persistenze e' una cosa davvero bella. In php si sente molto questa mancanza e in questo caso appunto a scandenza sessione se fosse possibile registrare gli handlers e stiparli in memoria del server ad avvio dell'applicazione sarebbe una bombardata.

Il problema e' chq in php la gestione custom delle sessione avviente tramite registrazione di funzioni (o classe + relativi metodi) ad avvio dello script. quindi tutte le operazioni di gestione sessione sono passate alle tue funzioni invece che alle procedure std di PHP.
MA, se quando una sessione va in timeout ? Che succede ? Non so se PHP la gestisca internamente con qualche listener .... so che se va in timeout dealloca i dati e amen.
Quindi non c'e' modo di sapere se la sessione e' in timeout se non controllato la timestamp dell'ultima op eseguita a riavvio della sessione ( alla prima read che viene eseguita).

La possibilità di gestire il garbage collector d'altro canto mi da la possibilità di fare un controllo su tutte le sessioni ogni volta che viene lanciata la mia procedura di garbage colletion. Il problema e' che tale procedura viene avviata quando ? ogni utente che ha una sessione e i relativi handlers puo' lanciarla ? Viene instanziata 1 volta sola e amen ? Se lo script termina viene deallocato tutto e tanti cari saluti alle mie procedure ?

Una bella soluzione sarebbe proprio la possibilità di gestire le persistenze, cosi' da poter creare correttamente le factory di gestione e al primo avvio dell'applicazione si carica l'ambiente che l'app deve usare e quindi non serve piu' re-istanziare nulla. Inserendo quindi gli handlers per le sessioni lo si fa la prima volta e basta poi sono pronti all'uso per ogni successiva necessita( con tanto sollievo del server che non deve riallocare / re-instanziare tutto ogni volta).

Ora cio' si puo' fare ?

Con PHP no.

ho fatto esperimenti e lavori su cose simili, ma non esattamente su un problema come quello che mi pare tu abbia... in effetti risolverlo direttamente forse non si può, ma con un artificio... ... ... (puntini di sospensione)

Ecco ho una risposta sconfortante ..... ma 1 risposta.

Peccato sarebbe il next step ... per php ... vabb penso che alla fine gestisco tutto come al solito e nelle procedure di read/write etc lancio il controllo sul timeout... e nel caso lancio il metodo destroy .... e mi tolgo il problema....

Grazie a totods

P.S.
peccato pero' ..... speriamo un giorno si possa fare .

Ciao!
Anche io ho risolto con una query che elimina le righe "vecchie". Non credo ci siano altre possibilità.
Nel mio caso avevo bisogno di memorizzare pochi dati testuali. Tu hai pensato anche al salvataggio di oggetti od array? Bisogna serializzarli?

CIao luke sto impostando la tabella in modo che sia personalizzabile, quindi la mia facotry instazia la classe passando anche la configurazione della tabella... (ma ci sto lavorando sopra su questo)

Di base salvo data di creazione, ultima modifica sessionId e i dati di sessione serializzati(vengono gia' passati cosi' quando php esegue il callback sulla tua procedura).

La read non deve fare altro che restituire i dati serializzati, in quanto anche la read viene chiamata come callback, e da documentazione ufficiale dicono che la procedura deve restituire una stringa con i dati serializzati oppure stringa vuota cosi' che la variabile super globale $_SESSION possa essere popolata dal chiamante.

Fatto cio non avrai problemi a gestire tali dati. I problemi iniziano se vuoi gestire i dati nella procedura per magari capire chista facendo cosa etc... a quel punto si devi deserializzarlima con attenzione ai caratteri | che fanno fallire le normali procedure di php. Cmq nell doc uff ci sono un sacco di info e funzioni gia' pronte che risolvono il problema.

Virus ma perche' utilizzare le sessioni invece di un'interfaccia diretta al DB? Non e' che stai reinventando la ruota di un ORM?

lol

beh 1 e' per esercizio mio, poi e' per poter capire chi sta facendo cosa e quando.
Siccome dovro gestire un sistema multiutente con azioni concorrenti, volevo poter gestire gli accessi alle entità con il modulo di gestione sessioni in modo da poter sfruttare le variabili di sessione per tracciare le operazioni invece di creare tabelle su db etc.... (il funzionamento non e' poi differnete nella modalità con sessioni std + tracciamento operazioni custom).

Il fatto e' che se riesco ad implementare la classe come voglio poi posso installare in software gi'a fatti e finiti senza dover necessariamente stravolgere il codice dell'applicazione per inserire lo strato di controllo (eventualmente anche le ACL) ..

Capisco che ci sono gia' e sono gia' state fatte con il loro funzionamento etc....
Ma volevo vedere.
Ho inoltre capito come e quando lancia le operazioni di open write etc... molto piu' precisamente di prima .

E appunto poi volevo fiunire la classe in modo da poterla gestire ove mi servisse avere un controllo piu' stretto sulle operazioni o sugli utenti. Ad esempio cosi' posso creare un pannello di controllo che mi dice chi e' loggato e quale' l'ultima operazione eseguita(volendo si puo' estendere il tracciamento poi a n operazioni ma per ora tengo solo l'ultima) .. posso quindi da pannello escludere utenti, o modificare le loro acl etc..... inoltre posso avere un controllo maggiore di cosa succede nelle sessioni.

Si quello che non ho capito e' perche' usare le sessioni. Per come la vedo io se devi mettere qualcosa in sessione di transitorio e' comodo perche' sono pronte, ci vuole un attimo e pensa a tutto PHP. Se pero' devi metterti a scrivere classi e relazioni complesse, allora che vantaggio hai a usare le sessioni invece di un tuo sistema di salvataggio dati, magari - appunto - con un ORM (anche fatto da te eh)?

Poi non so magari mi perdo qualcosa di figo nelle sessioni a cui non ho mai pensato

Stessa valutazione chenho fatto pure io... e ho deciso di capire perche' nn usar ei manager delle sessioni.

1 pensa ad un software gia0 fatto e finito ... vuoi mettere le ACL .... (tale software non e' fatto da te e nn e' fatto bene, con robe incluse acazzo etc.... ) metti le mani in tutto il software ... oppure serve soluzione alternativa che si sovrapponga senza toccare il resto del codice.

2 gli handler sono callback lanciati da php ad apertura / shiusura script quindi sai che partono a tempo "x" sopo aver fatto determinate operazioni indipendentemente dal resto del codice che inserisci.

3 hai il controllo di chi e' loggato senza dover appunto inserire codice di controllo nelle intestazioni ti basta registrare gli handlers dove hai le sezioni protette e sei apposto

Ci sono dei vantaggi, certo puoi tracciare lo stesso sfruttando altre classi in modo che le operazioni vengano tracciate manualmente non passando per la gestione sessioni ...
Ma se vuoi avere il controllo completo delle sessioni in corso in un sistema .... non credo ci sia altro modo ... ora mi sovviene la domanda... di base in php ... per leggere i dati di sessione ?
Devo sancsionare tutta una cartella di files se nn sbaglio ... cosi' invece sarebbero su database