Mal di sessioni
Monday, 11 August 08
Ecco lo scenario: stai comprando qualcosa online, e nel penoso processo di compilazione dei form multi-pagina a cui ti costringono proprio le persone a cui hai deciso di dare la tua fiducia (e i tuoi soldi) la tua contingenza umanoide ti rammenta tramite un gorgoglio addominale che forse sarebbe opportuno andare ad esplicare le tue funzioni primarie in bagno (c'è un sommergibile marrone senza elica e timone dentro me).
Quando torni premi "submit" ma la risposta è "sessione scaduta". Hai una rosa di possibilità a questo punto. Premi back e riprovi ma niente da fare di solito la sessione è iniziata al momento in cui hai inserito l'oggetto nel carrello, devi proprio rifare tutto da capo. Altra opzione, li mandi a quel paese e provi in un sito diverso, con poche garanzie che sarà migliore di questo. Terza opzione solitamente non utilizzabile se vivi a Campobello di Licata o altra località per cui la dicitura "dove ha perso le scarpe nostro signore" risulta appropriata: ti rechi in un simpatico negozio e acquisti la stessa cosa magari ad un prezzo un pò più alto ma subito e senza paranoie di spedizioni varie (opzione detta "pago e schifio" in Sicilia).
Se proprio dovete usare le sessioni quando sviluppate siti web almeno settate il timeout a una settimana, non vi preoccupate... nella vostra directory /tmp c'è abbastanza spazio ormai gli HD costano poco ;)
p.s. di solito le sessioni sono nemiche della scalabilità, infatti se non ci sono sessioni l'unico elemento che rimane problematico da scalare è il DB relazionale, perchè per i webserver basta averne più di uno con un bilanciatore che smista la richiesta in uno qualunque tra quelli disponibili. Se avete le sessioni bisogna avere il bilanciatore che gestisce la persistenza della sessione il che è meno performante, permette un bilancio meno preciso, non consente il recupero di quella sessione di navigazione se quel dato webserver si spacca e così via. Dunque a parte il timeout non sono una grande tecnica di programmazione ammenochè non implementate le sessioni direttamente tramite il DB. Io non le ho mai usate e non ne ho mai sentito la necessità.
Quando torni premi "submit" ma la risposta è "sessione scaduta". Hai una rosa di possibilità a questo punto. Premi back e riprovi ma niente da fare di solito la sessione è iniziata al momento in cui hai inserito l'oggetto nel carrello, devi proprio rifare tutto da capo. Altra opzione, li mandi a quel paese e provi in un sito diverso, con poche garanzie che sarà migliore di questo. Terza opzione solitamente non utilizzabile se vivi a Campobello di Licata o altra località per cui la dicitura "dove ha perso le scarpe nostro signore" risulta appropriata: ti rechi in un simpatico negozio e acquisti la stessa cosa magari ad un prezzo un pò più alto ma subito e senza paranoie di spedizioni varie (opzione detta "pago e schifio" in Sicilia).
Se proprio dovete usare le sessioni quando sviluppate siti web almeno settate il timeout a una settimana, non vi preoccupate... nella vostra directory /tmp c'è abbastanza spazio ormai gli HD costano poco ;)
p.s. di solito le sessioni sono nemiche della scalabilità, infatti se non ci sono sessioni l'unico elemento che rimane problematico da scalare è il DB relazionale, perchè per i webserver basta averne più di uno con un bilanciatore che smista la richiesta in uno qualunque tra quelli disponibili. Se avete le sessioni bisogna avere il bilanciatore che gestisce la persistenza della sessione il che è meno performante, permette un bilancio meno preciso, non consente il recupero di quella sessione di navigazione se quel dato webserver si spacca e così via. Dunque a parte il timeout non sono una grande tecnica di programmazione ammenochè non implementate le sessioni direttamente tramite il DB. Io non le ho mai usate e non ne ho mai sentito la necessità.
post letto 3080 volte (0.5 letture al giorno in media)
Postato alle 08:51:12 permalink | 2 commenti | stampa | posta | trackbacks
Io le uso, e sinceramente non posso farne a meno per certi progetti, ma costringono ad una serie di controlli (e relative query e bordelli vari) ad ogni submit.
Non è proprio il massimo della scioltezza in esecuzione. Ma fin quando la gente non capirà che cliccare logout non è peccato...