[Python] Re: Quale framework

[Manlio Perillo]

Nicola Larosa ha scritto:
> Manlio Perillo wrote:
>>>> La soluzione più semplice per integrare twisted.web2 con Django è usare
>>>> twisted.web2.wsgi, peccato che esegua l'applicazione in un thread e
>>>> questo a Django non piace (anche se non capisco perchè, probabilmente
>>>> colpa dell'ORM).
> 
>> Nicola Larosa ha scritto:
>>> Che vuoi dire? Non funziona?
> 
>> Non lo so ma nella documentazione per il deployment su mod_python
>> consigliano esplicitamente di non usare l'MPM worker di Apache.
> 
> Credo sia un misunderstanding. Mesi fa sono stati scoperti dei bachi usando
> mod_python su Apache con MPM. Credevo fossero stati risolti, ma comunque si
> tratta di un deployment in cui l'interprete Python gira dentro Apache, e le
> request vengono assegnate a dei thread di quell'interprete.
> 

Ok.

> Questo non significa che tutti gli altri deployment che usano i thread,
> come quelli tramite WSGI, siano soggetti agli stessi bachi, cosa che non mi
> risulta.
> 
> Ovviamente l'ideale, usando Twisted, sarebbe di non usare per niente i
> thread, o almeno limitarli all'indispensabile, come l'accesso al database.
> In quel caso non si può passare per WSGI, che non supporta gli eventi
> asincroni, ma bisogna scrivere un apposito handler di Django usando
> oculatamente i Deferred di Twisted (magari completando quello già iniziato
> che mi ritrovo casualmente sul disco ;-D ).
> 

Ti stai riferendo a:
http://code.djangoproject.com/ticket/2904
?


> A quel punto l'intera architettura è asincrona, tranne le parti dove si
> continuano a usare i thread, e bisogna seguire ovunque il principio guida
> di Twisted di non scrivere codice bloccante.
> 

La vedo ardua dato che puoi accedere a codice bloccante in modo non
controllabile quando usi un database.

Ad esempio, a quanto ho capito, viene usato sempre il lazy loading,
quindi una chiamata a obj.xxx può causare una query.

Una soluzione potrebbe essere quella di eseguire l'intera view in un
thread (e transazione) separati.

E' quello che volevo fare con Nevow, ma SQLAlchemy si è rivelato molto
flessibile.
Quello che ho fatto è stato semplicemente scrivere dei decoratori:

@engine.transact
def getXXXList(conn, ...):
    ...


@engine.transactSession
def getYYYList(conn, sess, ...):
    ...



Non ho idea se lo stesso si possa fare agevolmente con Django (e devo
dire che non ho molta voglia di indagare).




Saluti  Manlio Perillo