Bonjour,

Je me pose une question, donc, sur les transactions telles que gérées par jDb.

Lorsque je veux démarrer une transaction, j'utilie la méthode jDb::beginTransaction(), je fais ma tambouille, puis je "commite" par jDb::commit() ou je "rollbacke" par jDb::rollback(). Ca, ça marche nickel.

Imaginons maintenant que dans ma tambouille, j'appelle une fonction/méthode de classe qui fasse elle aussi son duo beginTransaction()+commit/rollback. Je ne suis pas sûr du comportement qui sera adopté...

En consultant le code de jDb et de son plugin MySQL, j'aurai tendance à penser que le commit ou le rollback de la fonction/méthode va désactiver totalement la transaction. J'ai bon ?

Maintenant, si c'est bien le comportement, en mettant en place un système qui permet de désactiver les transactions uniquement lorsque le dernier commit/rollback est atteint, est-ce que je déconne complètement ?

Merci de vos commentaires attendus avec impatience :-p

Salut,

à priori, c'est la base de donnée qui gère ça. Dans mysql, les transactions ne peuvent pas être imbriquées, et dés que tu fait un begin, ça commit la transaction en cours avant d'en demarrer une nouvelle.

Donc c'est à toi de gérer les transactions, c'est à dire te débrouiller pour ne pas en avoir d'imbriquée.

OK, c'est bien ce qu'il me semblait pour MySQL.

Comme je ne peux pas faire en sorte de ne pas avoir de transaction imbriquée, mon idée de faire une classe qui "encapsule" les transactions (au moins pour MySQL) n'est pas déconnante.

Merci !