Philip Thompson wrote:
> Hi all.
>
> I'm currently working on a project that's in its beta stage. Due to time
> restraints, we were unable to build in transactions from the beginning.
> Well, we're getting to the point where we can now put in transactions.
> Basically, I'm curious to find out your opinion on the best way to
> accomplish this.
>
> Currently, my thoughts for doing this are:
>
> <?php
> function someFunctionThatNeedsTransactions ()
> {
> $this->db->begin(); // Start transaction
> $this->db->query("SELECT..."); // Run my queries here
> $this->db->query("UPDATE...");
> // Do some PHP logic here
> $this->db->query("SELECT..."); // Run more queries
> $this->db->query("INSERT...");
> $this->db->commit(); // Commit transaction
> }
> ?>
>
> If there was a failure in one of the queries, that would be caught in
> the database class ('db' instance) and <?php $this->rollback(); ?> would
> be called. Note that all the tables are InnoDB and the above
> code/functionality works.
>
> Ideally, I would have liked to use stored procedures, but that decision
> was not mine. So are there any complications I'm potentially missing?
I'd get your db class to handle nested transactions, so if you had
something like this:
$db->begin();
....
someFunctionThatNeedsTransactions();
...
.. oops, need to rollback.
$db->rollback();
the bits between "someFunction" and the "rollback" will be committed (by
the function) and can't be rolled back.
See http://dev.mysql.com/doc/refman/5.0/en/savepoints.html
The situation might not come up but it can't hurt to have it already
built in "just in case".
--
Postgresql & php tutorials
http://www.designmagick.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
