[PHP] autocommit e rollback

[Swalke]

Ciao a tutti.
Non riesco a trovare una risposta esauriente a questo mio dubbio.

In php, una volta che setto l'autocommit a false, che differenza c'è tra eseguire un rollback oppure non eseguire il commit?

Ad esempio ammettiamo che se si verifica un errore io devo evitare che le modifiche vengano scritte sul db.

Che differenza c'è tra questi due codici:

$mysqli->autocommit(FALSE);
$mysqli->query("INSERT INTO Language VALUES ('DEU', 'Bavarian', 'F', 11.2)");
if($mysqli->error=='')
{
//altre operazioni varie
$mysqli->commit();
}
else
{
header('location:error.php')
}


$mysqli->autocommit(FALSE);
$mysqli->query("INSERT INTO Language VALUES ('DEU', 'Bavarian', 'F', 11.2)");
if($mysqli->error=='')
{
//altre operazioni varie
$mysqli->commit();
}
else
{
$mysqli->rollback();
header('location:error.php')
}

A mio giudizio nessuna.
Se con l'autocommit a false il commit avviene solo quando lo invoco, non serve che faccio il rollback nel caso in cui non voglio che avvengano le modifiche. Mi basta non invocare il commit no? :mbe:

[Swalke]

[up] please :(

[Ed_Bunker]

Mmm... interessante... ripensandoci bene, pero', sembrerebbe che con l'autocommit a false le modifiche vengano cmq. apportate ma che tali modifiche NON SI DEBBANO RITENERE PERMANENTI fintanto che non ne viene effettuato, appunto, il commit.
Per cui non effettuando ne' il commit ne' il rollback ci si potrebbe forse trovare in uno stato "transiente"/inconsistente ?!?

[Swalke]

sembrerebbe che con l'autocommit a false le modifiche vengano cmq. apportate
Devo contraddirti Ed_Bunker.
Se io metto autocommit a false, le modifiche non avvengono!

[Ed_Bunker]

Devo contraddirti Ed_Bunker.
Se io metto autocommit a false, le modifiche non avvengono!
Non saprei...
La "teoria" dice che con l'autocommit a false le modifiche NON SONO PERMANENTI il che significa che e' possibile annullarle mediante un apposito rollback.
Per cui le modifiche potrebbero anche essere temporaneamente apportare con la differenza che esiste un punto di "ripristino" mediante il quale e' possibile "tornare indietro".

La PERMANENZA viene "stabilita" con la chiamata al metodo "commit".

Ora... la domanda posta non e' affatto banale anzi... e non so come stiano effettivamente le cose.

[Ed_Bunker]

Anzi... il problema credo che ci sia eccome.

Senza effettuare un commit o un rollback la transazione rimane aperta.

Per cui, in funzione del livello di isolamento impostato, altre applicazioni/thread/utenti non potranno avere accesso al db o alle "righe" selezionate durante la transazione ancora "in corso".

[Ed_Bunker]

Come pensavo.

Tratto da un tutorial della (Mitica) SUN:


...
In this example, auto-commit mode is disabled for the connection con, which means that the two prepared statements updateSales and updateTotal are committed together when the method commit is called. Whenever the commit method is called (either automatically when auto-commit mode is enabled or explicitly when it is disabled), all changes resulting from statements in the transaction are made permanent.
...
The final line of the previous example enables auto-commit mode, which means that each statement is once again committed automatically when it is completed. Then, you are back to the default state where you do not have to call the method commit yourself. It is advisable to disable auto-commit mode only while you want to be in transaction mode. This way, you avoid holding database locks for multiple statements, which increases the likelihood of conflicts with other users.

[Swalke]

Certo!
Hai perfettamente ragione, il rollback o il commit sono d'obbligo altrimenti resta loccato il db per impedire la concorrenza.

Grazie mille!

[Ed_Bunker]

Grazie a te per avermi fatto (Lungamente !!) riflettere su una cosa che "davo per scontato".
Considera, tuttavia, che il problema potrebbe essere piu' o meno "grave" a seconda del livello di isolamento impostato.