Serialization failure: aie aie ai !!! Deadlock

[php_addict]

Ne sois pas si désinvolte, c'est une très bonne chose. De plus, ton code en sortira simplifié.

pourquoi simplifié en serait le code? (oulala ca fait un peu star wars cette phrase...)

je me suis dis ceci:

-lors de l'ajout d'un action (on enregistre en base de donnée l'action) et on met egalement dans la queue (redis/resque) cette action, de telle sorte qu'il y ai un enregistrement en dur (mysql) et un enregistrement en RAM (redis/resque) des actions, genre en cas de plantage serveur, ou redémarrage serveur, on a pas trop le choix en fait je crois...

ainsi les actions peuvent etre resolues de façon synchrone (rafraichissement de page) quand le système de queue est off ou down, et de façon assynchrone quand le système de queue est operationel. Le hic c'est de switcher de l'un à l'autre...euh je sais pas si c'est très clair...

le cas le plus pourri etant:

- on a une queue d'action bien foutue, des actions à résoudre, tout se passe bien. les workers feront le job...
- le serveur plante, ou redemarre et crac! la ram de redis est vide, les actions à resoudre ne sont plus dans la queue
==> ca se passe comment, il faut bien recharger les actions dans la queue (d'où l'utilité de les avoir sauvegardées en base mysql....)

comprends pas comment il est possible de determiner "je resoud assynchrone" ou "synchrone"...

vous me suivez? ou je délire totalement?

Tu as une seule requête avec transaction mais peut-être que deux requêtes web la lancent en même temps ?

oui c'est forcement ca à y bien penser...et du coup ma transaction fait bien son job, à savoir éviter les concurences d'accès à la base de donnée, donc ce genre de deadlock est vital pour l'integrité des données des actions à résoudre...

PS: bon ca y est mon serveur dédié est installé sur mon vieux pc tout pourrage, je vais pouvoir tester php resque tranquillement, ca va etre quand même bien chaud cette histoire de jobs schedulding...