More transaction questions!
What I have right now is a mess of strung-together queries, that are all manually reversed if any fail:
Code Block 1
$stmt1 = $db->prepare(...); // Update table1, set col=col+1
if($stmt1 = $db->execute(...)){
$stmt2 = $db->prepare(...); // Insert into table2, id=12345
if($stmt2 = $db->execute(...)){
$stmt3 = $db->prepare(...); // Select val from table3
if($stmt3 = $db->execute(...)){
$result = $stmt3->fetchAll();
if($result[0]['val'] == something){
$stmt4 = $db->prepare(...); // Update table4, set status=2
if($stmt4 = $db->execute(...)){
return true;
}else{
$stmt1 = $db->prepare(...); // Update table1, set col=col-1 (opposite of above)
$stmt1 = $db->execute(...);
$stmt2 = $db->prepare(...); // Delete from table2, where id=12345 (opposite of above)
$stmt2 = $db->execute(...);
return false;
}
}
return true;
}else{
$stmt1 = $db->prepare(...); // Update table1, set col=col-1 (opposite of above)
$stmt1 = $db->execute(...);
$stmt2 = $db->prepare(...); // Delete from table2, where id=12345 (opposite of above)
$stmt2 = $db->execute(...);
return false;
}
}else{
$stmt1 = $db->prepare(...); // Update table1, set col=col-1 (opposite of above)
$stmt1 = $db->execute(...);
return false;
}
}
It's a mess, difficult to debug, difficult to add on to, difficult to understand when the queries are large, and won't return all tables back to original state if the connection is lost mid-way through.
This same process is even worse when deleting a row, because everything in it needs to be stored - just in case the operation needs to be undone.
Now, I know most of this will still work when I port it over to a single transaction, but the one part I am unsure of is:
Code Block 2
$result = $stmt3->fetchAll();
if($result[0]['val'] == something){
... continue ...
}else{
... reverse operations ...
return false;
}
Because the results-gathering would take place before the commit() in the transaction. As follows:
Code Block 3
$db->beginTransaction();
try{
$stmt1 = $db->prepare(...);
$stmt1->execute();
$stmt2 = $db->prepare(...);
$stmt2->execute();
$stmt3 = $db->prepare(...);
$stmt3->execute();
$result = $stmt3->fetchAll();
if($result[0]['val'] == something){
$stmt4 = $db->prepare(...);
$stmt4->execute();
}else{
$db->rollBack();
return false;
}
$db->commit();
return true;
}catch(Exception $e){
$db->rollBack();
throw $e;
return false;
}
Will this work? Specifically, can I include the $result = $stmt3->fetchAll(); before the commit(), and then execute the conditional query?
Also, I'm not entirely sure on this, but do I require the $db->rollBack(); within the try block, if the code is exited (return false) before the commit()?
Your first question:
Specifically, can I include the $result = $stmt3->fetchAll(); before the commit(), and then execute the conditional query?
I see no reason why it should not work. A transaction behaves basically the same as operations without transactions - except that changes are only drafts. Any changes you make in the previous statements will be applied to a "working copy" valid for this single session only. For you it will appear completely transparent. However any changes will be rolled back if you do not commit them.
Also worth noting (emphasis mine):
In layman's terms, any work carried out in a transaction, even if it is carried out in stages, is guaranteed to be applied to the database safely, and without interference from other connections, when it is committed.
This can cause racing conditions.
Your second question:
Also, I'm not entirely sure on this, but do I require the $db->rollBack(); within the try block, if the code is exited (return false) before the commit()?
From the documentation it says:
When the script ends or when a connection is about to be closed, if you have an outstanding transaction, PDO will automatically roll it back.
Therefore you do not necessarily require to roll back manually as it will be done by the driver itself.
However note the following from the same source as well:
Warning PDO only checks for transaction capabilities on driver level. If certain runtime conditions mean that transactions are unavailable, PDO::beginTransaction() will still return TRUE without error if the database server accepts the request to start a transaction.
So be sure to check the compatibility beforehand!
A few notes
Do NOT begin a transaction in another transaction. This will commit the first transaction implicitely. See this comment.
Another note from the documentation:
Some databases, including MySQL, automatically issue an implicit COMMIT when a database definition language (DDL) statement such as DROP TABLE or CREATE TABLE is issued within a transaction. The implicit COMMIT will prevent you from rolling back any other changes within the transaction boundary.
Related
Here is my script:
$id = $_GET['id'];
$value = $_GET['val'];
// database connection here
try{
$db_conn->beginTransaction();
// inserting
$stm1 = $db_conn->prepare("INSERT into table1 (col) VALUES (?)");
$stm1->execute(array($value));
// updating
$stm2 = $db_conn->prepare("UPDATE table2 SET col = "a new row inserted" WHERE id = ?");
$stm2->execute(array($id));
$db_conn->commit();
}
catch(PDOException $e){
$db_conn->rollBack();
}
All I want to know, can I use an if statement in the codes which are between beginTransaction() and commit() ? Something like this:
$id = $_GET['id'];
$value = $_GET['val'];
// database connection here
try{
$db_conn->beginTransaction();
// inserting
$stm1 = $db_conn->prepare("INSERT into table1 (col) VALUES (?)");
$stm1->execute(array($value));
// updating
if (/* a condition here */){
$stm2 = $db_conn->prepare("UPDATE table2 SET col = "a new row inserted" WHERE id = ?");
$stm2->execute(array($id));
}
$db_conn->commit();
}
catch(PDOException $e){
$db_conn->rollBack();
}
Can I ?
Actually I asked that because here is a sentence which says you can't and doing that is dangerous:
Won't work and is dangerous since you could close your transaction too early with the nested commit().
There is no problem with your transaction structure. The comment on php.net only means, that MySQL does not support nested transactions. In order to your further question, you can query any data (SQL), manipulate data (DML), but not modify any database structures (DDL - data definition language).
/*won't work*/
START TRANSACTION;
/*statement*/
START TRANSACTION; /*nested not supported, auto commit*/
/*statement*/
COMMIT;
/*statement dependend on 1st transaction won't work*/
COMMIT;
See also MySQL ref
Transactions cannot be nested. This is a consequence of the implicit commit performed for any current transaction when you issue a START TRANSACTION statement or one of its synonyms.
You can do everything within a transaction, the only thing you cannot do is nest transactions.
Not the if clause itself is the problem in your linked comment, but the fact there is another beginTransaction / commit pair inside.
Here is my script:
try{
$db_conn->beginTransaction();
$stm1 = $db_conn->prepare("UPDATE table1 SET col = 'updated' WHERE id = ?");
$stm1->execute(array($value));
$done = $stm->rowCount();
if ($done){
try {
$stm2 = $db_conn->prepare("INSERT into table2 (col) VALUES (?)");
$stm2->execute(array($id));
} catch(PDOException $e){
if ((int) $e->getCode() === 23000) { // row is duplicate
$stm3 = $db_conn->prepare("DELETE FROM table2 WHERE col = ?");
$stm3->execute(array($id));
} else {
$db_conn->rollBack(); -- this
}
}
} else {
$error = true;
}
$db_conn->commit();
}
catch(PDOException $e){
$db_conn->rollBack();
}
As you see there is a rollBack() before commit() (where I've commented by -- this). Well is what I'm doing correct? Or that rollBack() is useless?
Note: that DELETE statement acts as an undo. Suppose you give a vote to a post and you want to take it back. So that DELETE statement remove it if you send a vote twice.
You dont need to make it quite so complicated.
You can run the 2 queries within a single try/catch as any of the queries that has an isse will throw an exception, and then you can do a single rollback.
If the first query fails, the database will not be changed, the rollback will just close the transaction. If the second query fails the rollback will UNDO the first query i.e. the UPDATE you did previously.
If both queries complete OK, the commit will apply the changes to the database.
try{
$db_conn->beginTransaction();
$stm1 = $db_conn->prepare("UPDATE table1 SET col = 'updated' WHERE id = ?");
$stm1->execute(array($value));
$stm2 = $db_conn->prepare("INSERT into table2 (col) VALUES (?)");
$stm2->execute(array($id));
$db_conn->commit();
}
catch(PDOException $e){
$db_conn->rollBack();
}
ADDITIONAL NOTES
I see what you think you were trying to do. BUT!
If the INSERT fails with a 23000 error code, then the INSERT will not have been done. Your unnecessary attempt to delete the failed INSERT will actually DELETE the row that was there originally i.e. the original vote that should not be deleted!
Your code would work fine. You can get rid of your inner rollback if you would rethrow your error (that would be the "standard way"):
try {
...
if ($done){
try {
...
} catch(PDOException $e){
if ((int) $e->getCode() === 23000) { // row is duplicate
...
} else {
throw $e;
}
}
...
} else {
$error = true;
}
$db_conn->commit();
}
catch(PDOException $e){
$db_conn->rollBack();
}
In this case, your final rollback will handle all exceptions that should be rolled back, while handling the one exception 23000 yourself without rollback.
And it would work fine in your code too. Technically, you can in fact combine as many commits and rollbacks as you want without resulting in an error - if you commit after a rollback, it will just commit nothing, because it rolled back already. If you use rollback without start transaction (in autocommit mode), it will just do nothing. It is just a little harder to maintain the code and to see the strcuture, that's why you usually would use the "standard way" above.
There is just one important thing to consider: transactions in mysql are not nested. If you use start transaction, it will automatically do a commit before that. So e.g.
start transaction;
delete from very_important_table;
start transaction; -- will do an autocommit
rollback;
rollback; -- will have no effect;
commit; -- will have no effect;
rollback; -- will have no effect;
will not rollback your very_import_table, because the 2nd start transaction already committed it.
I've written this code to ensure that two users can't edit the same row of the same table at the same time. The only problem that I have with it, is that it connects to the database 3 times, once to add a new lock, once to check that it's the only lock for that row and once to either delete the lock or to retrieve the data for the user to edit. I really don't like this, but it was the only way that I could imagine doing it.
Are there any ways of making this more efficient?
<?php
$CountryID = $_GET["CountryID"];
$userID = $_SESSION["userID"];
$currentTime = date('Y-m-d H:i:s');
try{
include_once 'PDO.php';
//Adds a new lock into the database.
$dbh->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );
$sth = $dbh->prepare('INSERT INTO lock (UserID, TableID, RowID) VALUES (?, ?, ?)');
$sth->execute(array($userID,1,$CountryID));
$insertedID = $dbh->lastInsertId();
//Checks to see if there is more than one lock for this table/row. If there is more than 1 row, it will check to make sure that all OTHER rows are older than 5 minutes old incase of broken locks.
$sth = $dbh->prepare('SELECT * from lock where TableID = ? AND RowID = ?');
$sth->execute(array(1,$CountryID));
$rowCount = $sth ->rowCount();
$locked = false;
if ($rowCount >1 ){
foreach($sth as $row){
if ($row['LockID'] != $insertedID AND (abs(strtotime($currentTime) - strtotime($row['Date']))) < 300){
$locked = true;
break;
}
}
}
if ($locked){
//Delete the lock we put in first, and tell the user that someone is already editing that field.
$sth = $dbh->prepare('DELETE from lock where LockID = ?');
$sth->execute(array($insertedID));
echo "Row is currently being edited.";
}else{
//Don't delete the lock, and get data from the country table.
echo "Row isn't being edited.";
$sth = $dbh->prepare('SELECT * from country where CountryID = ?');
$sth->execute(array($CountryID));
}
}catch (PDOException $e){
echo "Something went wrong: " . $e->getMessage();
}
$dbh = null;
?>
It looks like you want a scheme for advisory persistent locking. That is, you want to keep the locks in place for a relatively long time -- longer than a DBMS transaction could reasonably expect to do from a web app. I call it "advisory" because it's not "mandatory" in the sense that the DBMS enforces it.
You are very close. I suggest you define your lock table with a compound primary key (TableID, RowID). That way, attempts to insert duplicate records into that table will fail. Forget about the LockID. You don't need it. UserID is helpful because it will give you a hint at diagnosing trouble.
Then, to set up a lock (in your example on table 1, row $CountryID) you will do your insert like so:
$dbh->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION ); /* only once*/
$sth = $dbh->prepare('INSERT INTO lock (UserID, TableID, RowID) VALUES (?, ?, ?)');
$locked = true;
try {
$sth->execute(array($userID,1,$CountryID));
}
catch (PDOException $e) {
$locked = false;
}
This is nice because you'll handle the duplicate-key error (integrity constraint violation) by setting $locked to false. When $locked is false you know somebody else has the lock and you can't have it. It's also nice because it's race-condition-proof. If two users are racing to take the same lock, one of them definitively wins and the other definitively loses.
When you want to release the lock, do the delete in a similar fashion.
$sth = $dbh->prepare('DELETE FROM lock WHERE TableID = ? AND RowID = ?');
$it_was_locked = false;
$sth->execute(array(1,$CountryID));
if ($sth->rowCount() > 0) {
$it_was_locked = true;
}
Here, the variable $it_was_locked lets you know whether the lock was already in place. In any case after you run this command the lock will be cleared.
One more thing. For the integrity of your system, please consider defining a lock timeout. Perhaps it should be ten seconds, and perhaps it should be ten hours: that's up to your application's user-experience needs. The timeout will keep your application from getting all jammed up if people start but don't complete transactions.
Then, put a locktime column into your lock table and automatically put the current time into it. You'd do this with a line like this in your table definition.
locktime TIMESTAMP DEFAULT CURRENT_TIMESTAMP
Then, whenever you insert a lock, first release all locks that have timed out, like so.
$stclean = $dbh->prepare('DELETE FROM lock WHERE locktime < NOW() - 10 SECOND');
$sth = $dbh->prepare('INSERT INTO lock (UserID, TableID, RowID) VALUES (?, ?, ?)');
$locked = true;
$stclean->execute();
if ($stclean->rowCount() > 0) {
/* some timed-out locks were released; make an error log entry or whatever */
}
try {
$sth->execute(array($userID,1,$CountryID));
}
catch (PDOException $e) {
$locked = false;
}
This kind of thing makes for a serviceable locking scheme. When you're doing system test, you can expect to look at this lock table a lot, trying to figure out what module forget to take a lock and what module forgot to release it.
My queries are working no matter if all queries from transaction weren't successfully executed.
$this->mysqli->autocommit(FALSE);
$query = $this->mysqli->real_escape_string("INSERT INTO `product` (`name`, `price`) VALUES (?,?)");
$prod = $this->mysqli->prepare($query);
$prod->bind_param("ss", $name,$price);
$prod->execute();
$query = $this->mysqli->real_escape_string("INSERT INTO `member` (`user`, `address`) VALUES (?,?)");
$prod = $this->mysqli->prepare($query);
$prod->bind_param("ss", $user,$address);
$prod->execute();
$query = $this->mysqli->real_escape_string(" SOME BAD WRITTEN QUERY") ;
$prod = $this->mysqli->prepare($query);
$prod->execute();
if (!$this->mysqli->commit())
{
print("\nTransaction commit failed\n");
$this->mysqli->rollback();
}
$this->mysqli->autocommit(TRUE);
This code is working and inserting first two queries, of course breaks on third.
But transaction isn't working, no matter what it will insert every query that works, and I want to insert only if all three queries are done properly.
I use INNODB engine and PHP 5.5
When the transaction has been implicitly started since autocommit was disabled, MySQL is not internally tracking the success state of the statements you execute. That is your job as the programmer. So even if SOME BAD WRITTEN QUERY fails, the previous two succeeded and can be committed.
You must test for the success of each and commit() or rollback() accordingly:
Note: You should not call real_escape_string() on the SQL statements. It is potentially harmful, and definitely not necessary for the prepared statement string.
$this->mysqli->autocommit(FALSE);
$query = "INSERT INTO `product` (`name`, `price`) VALUES (?,?)";
$prod = $this->mysqli->prepare($query);
$prod->bind_param("ss", $name,$price);
// Store success/fail in a variable (returns TRUE on success)
$success1 = $prod->execute();
$query = "INSERT INTO `member` (`user`, `address`) VALUES (?,?)";
$prod = $this->mysqli->prepare($query);
$prod->bind_param("ss", $user,$address);
// Store success/fail in a variable (returns TRUE on success)
$success2 = $prod->execute();
$query = " SOME BAD WRITTEN QUERY";
$prod = $this->mysqli->prepare($query);
// Store success/fail in a variable (returns FALSE on failure)
$success3 = $prod->execute();
// Now check if all 3 succeeded and commit() if they did
if ($success1 && $success2 && $success3)
{
$this->mysqli->commit();
}
// Or rollback() if they didn't
else
{
print("\nTransaction commit failed\n");
$this->mysqli->rollback();
}
$this->mysqli->autocommit(TRUE);
A final note. If you are only disabling autocommit for a single transaction then re-enabling it, consider just leaving autocommit enabled and explicitly beginning and ending the transaction. Instead of calling $this->mysqli->autocommit(false) and later $this->mysqli->autocommit(true);, just call
// Don't disable autocommit
// Start it...
$this->mysqli->begin_transaction();
// Do your 3 queries as above and test for success
// Then commit or rollback
$this->mysqli->commit();
// (or rollback)
// Now, no need to re-enable auto-commit
If your application will use lots of transactions, then by all means disable autocommit. You'll need to explicitly commit() after every action, but I wouldn't disable it just to reenable it after one transaction.
And a note about DDL statements - MySQL cannot rollback DDL statements, and I believe calling one mid-transaction will cause all the previous statements to be committed, even though you have not yet explicitly called commit(). So beware of this if you are issuing CREATE,ALTER,DROP statements from your code. They cannot be used with transactions.
as #gloomy.penguin says, you need to mysqli->begin_transaction() before you send the first transaction and then mysqli->commit() at the end.
disabling autocommit and then enabling autocommit is unnecessary unless of course you have more code that commits later.
I'm working on a school project creating a CMS for my portfolio site. I am having trouble getting my update function to work. I have a feeling it has something to do with the way I'm constructing my PDO Transaction. In my database I have a projects table, category table, and the associative content_category table. I'm able to insert my projects into those tables just fine. What I want to do is insert into my projects table then delete all records from the content_category table and finally insert the current category records into that associative table to complete the transaction. I do get my return statement "Project Updated" returned. But the tables aren't being updated. Any ideas anyone?
Here's the code:
This is a function in my Project class.
public function update(){
try {
$conn = getConnection();
$conn->beginTransaction();
$sql = "UPDATE project
SET project_title = :title,
project_description = :desc,
project_isFeatured = :feat,
project_mainImage = :image
WHERE project_id = :id";
$st = $conn->prepare($sql);
$st->bindValue(":id", $this->id, PDO::PARAM_INT);
$st->bindValue(":title", $this->title, PDO::PARAM_STR);
$st->bindValue(":desc", $this->description, PDO::PARAM_STR);
$st->bindValue(":feat", $this->isFeatured, PDO::PARAM_BOOL);
$st->bindValue(":image", $this->mainImage, PDO::PARAM_INT);
$st->execute();
$sql = "DELETE from content_category
WHERE content_id = :id";
$st = $conn->prepare($sql);
$st->bindValue("id", $this->id, PDO::PARAM_INT);
$st->execute();
$sql = "INSERT into content_category (content_id, cat_id)
VALUES (?,?)";
$st = $conn->prepare($sql);
foreach($this->categories as $key=>$value){
$st->execute(array(intval($projectID), intval($value)));
}
$conn->commit();
$conn = null;
return "Project updated";
}
catch(Exception $e) {
echo $e->getMessage();
$conn->rollBack();
return "Error... Unable to update!";
}
}
Your database engine for the tables needs to be INNODB. If you are using phpMyAdmin, it defaults to MyISAM. (I don't know if that will cause the updates not to go through or just the transaction line to be ignored. Edit: Pretty sure the documentation is saying that it will throw an error and not do anything if you beginTransaction on a myISAM)
In order to make sure you are not encountering a PDO error, you should set the PDO error reporting like this:
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
There are functions in PDO such as prepare() which will either return false or throw a PDOException depending on what error mode is set. This way, it will throw an exception and you'll definitely know if you are having a problem!
Also, if your database doesn't support transactions (like MyISAM), the beginTransaction() function will return false. So, maybe add a check in there like:
if($conn->beginTransaction()) {
// Do transaction here
} else {
echo("Unable to use transactions with this database.");
}
Oddly enough, according to PHP documentation, you would be getting an exception if your database doesn't support transactions...
Unfortunately, not every database supports transactions, so PDO needs to run in what is known as "auto-commit" mode when you first open the connection. Auto-commit mode means that every query that you run has its own implicit transaction, if the database supports it, or no transaction if the database doesn't support transactions. If you need a transaction, you must use the PDO::beginTransaction() method to initiate one. If the underlying driver does not support transactions, a PDOException will be thrown (regardless of your error handling settings: this is always a serious error condition).
Commit returns TRUE on success or FALSE on failure. You can check it. Also check for errorCode.