2015-09-17 15:41 GMT+02:00 Manlio Perillo <manlio.peri...@gmail.com>:
> L'esempio di Glyph è molto complesso e non so nemmeno se è possibile > sviluppare una libreria generica > per risolvere quel genere di problemi. Ad esempio STM (software > transactional memory) non aiuta in questo caso, perchè lo > stato potrebbe essere su un server remoto, e non in memoria. > io direi che è un esempio classico nella vita reale, se apri il portafogli e prelevi i soldi, lo fai uno per volta. Se infili 2 mani, va a finire che i soldi si strappano. un altro portafogli può andare in parallelo. ora se questo lo vuoi risolvere con i thread o con i processi ti poni sempre limiti di scalabilità. il problema si deve risolvere alla fonte, ossia nel punto dove sta il portafogli. se è in un DB relazionale, in un DB relazionale. Il problema si pone complicato quando i portafogli si trovano su due componenti lontane tra loro. E via con le XA transactions. A livello di design si risolve serializzando i task, non con costrutti dei linguaggi o delle magie architetturali. Vuoi spostare i soldi, bene comincia a chiedere di farlo, e poi deleghi il tesoriere del conto che fa i conti uno per volta. Se sei smart riesci ad avere anche un pool di banchieri. Per risolvere i problemi di database diversi il politico deve assoldare i controllori che dopo le registrazioni dei tesorieri e le magagne dei banchieri vanno a pizzicare gli errori. Insomma niente di nuovo... tutto irregolare come nella vita reale
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python