Re: Database transactions with PEAR DB
| From: | Stig S. Bakken | Date: | Tue, 29 Jan 2002 21:08:35 +0000 |
| Subject: | Re: Database transactions with PEAR DB | ||
| References: | 1 | Groups: | php.pear.general |
| Request: | Send a blank email to pear-general+get-750@lists.php.net to get a copy of this message | ||
On Tue, 2002-01-29 at 16:55, derek fong wrote:
> On 1.29.02 8:37 am, "Stig S. Bakken" <ssb@alltheweb.com> wrote:
>
> > On Tue, 2002-01-29 at 14:23, derek fong wrote:
> >> Hello,
> >>
> >> I have written a PHP application that may be used with either Oracle or
> >> MySQL. There is one section of it that would probably benefit from being
> >> within a database transaction. Although I've been able to find methods like
> >> autoCommit, rollback and commit, I can't seem to find the relevant function
> >> to actually start the transaction and finish it off, at least where Oracle
> >> is involved. Would it suffice to just set autocommit to false, issue my
> >> queries and commit/rollback when I'm done?
> >>
> >> Can someone shed some light on this? I've read about alternate DB classes I
> >> could use, but I would prefer to stick with the PEAR DB class since it's
> >> already been used exclusively for the project.
> >
> > Hi,
> >
> > Yes, you start a transaction simply by turning off autocommit (which is
> > always on by default), and complete it with a call to commit or
> > rollback.
>
> Great! Is there a way to determine whether or not the current RDBMS
> actually supports transactions? I see some references to a "provides"
> method, but can't actually find it anywhere. I want my app to determine if
> the transaction was actually "rolled back" in the database. AFAIK, mysql
> 3.23.47 doesn't support real transactions, yet issuing ROLLBACK/COMMIT
> statements don't produce errors in the mysql client. Under what
> circumstances would the rollback() and commit() functions return error
> conditions?
If you try doing an operation that the backend database does not
support, you will get a DB_ERROR_NOT_CAPABLE error back.
Here is "the PEAR way" of handling this error gracefully:
$dbh->expectError(DB_ERROR_NOT_CAPABLE);
$err = $dbh->autoCommit(false);
if (PEAR::isError($err) && $err->getCode() == DB_ERROR_NOT_CAPABLE) {
die("whoops, no transaction support!");
}
$dbh->popExpect();
The reason for using expectError() and popExpect() is in case you have
defined a PEAR error handler, when handling errors gracefully you
probably want to avoid it. Just drop the first and last line if you
won't need that.
- Stig