[Python] web2py: lo conoscete -> sessioni su db

[Daniele Varrazzo]

On Mon, 12 Dec 2011 18:49:38 +0100, Alessandro Dentella wrote:
> On Fri, Dec 02, 2011 at 03:37:34PM +0000, Daniele Varrazzo wrote:
>> Ah, cherrypy è multithread, ma lo storage su file delle sessioni non
>> è thread safe, me lo sono dovuto scrivere io. Mi chiedevo come mai
>> l'autore originale del programma usasse memcached solo per salvare
>> (si fa per dire le sessioni). Quando abbiamo fatto il multi-nodo, un
>> mio collega ha visto lo storage delle sessioni su database (che
>> potrebbe servirci se volessimo scalare su diverse macchine) e ha
>> detto che anche quello è finto.
>
> Nel cammino verso l'indipendenza dell'applicativo dal processo voglio
> portare le sessioni su database.

Uhm... ok... su file non vanno più bene? Assumo che lo vogliate fare 
per scalare oltre la singola macchina, altrimenti non c'è ragione.


> Considerando che attualmente le singole request vengono evase in 100 
> ms
> circa, pensavo di farlo utilizzando SELECT FOR UPDATE, così da 
> garantirmi
> che nessun'altra request possa leggere finché non ho evaso la 
> request.

E perché vorresti impedire di leggere? Uno fa tanto per progettare un 
database che consenta letture e scritture concorrenti e tu infili gli un 
ombrello nella ruota davanti? :)


> Ci sono idee migliori o controindicazioni? (a parte che tengo 
> occupata una
> connessione solo per questa transazione)

Controindicazioni dei lock espliciti? Quante ne vuoi. Non è una buona 
idea. Sono pochi i problemi che hanno davvero bisogno di un lock per 
essere risolti, e tu non sei neanche sicuro di avere un problema: ti 
direi lascia perdere che rischi di fare più danni di quelli di cui hai 
bisogno.


> Guadando il codice di django non ci leggo precauzioni contro questa
> eventualità, mi sfuggono o cherry-py non è solo?

Forse semplicemente non è un problema. Se hai un burst di letture sullo 
stesso utente dovuto a richieste asincrone, dovrebbero leggere tutte uno 
stato consistente della sessione. I problemi di cherrypy sono 
ridicolamente altri, secondo me django due o tre persone l'hanno testato 
e va bene così com'è. Con cherrypy a volte le sessioni leggevano un file 
e lo trovavano vuoto perché la richiesta di prima l'aveva aperto per 
scrivere (con open(name, 'w')) e non l'aveva ancora chiuso; con postgres 
questo problema non esiste: o il vecchio, o il nuovo, ma un record 
consistente ce lo trovi. Le sessioni su postgres di cherrypy erano finte 
perché mancavano dei metodi che servivano, proprio pezzi non scritti e 
oggetti mai usati, non avevano problemi di concorrenza. Di esistenza, 
casomai.

A proposito, poi com'è andata con la storia di tornado e psycopg?


-- 
Daniele Varrazzo - Develer S.r.l.
http://www.develer.com