Date: 07/09/00
- Next message: Manuel Lemos: "Re: [PHP-DEV] *crash* on try to find out how many nestinglevelsare allowed"
- Previous message: Andi Gutmans: "Re: [PHP-DEV] Extensions calling C++"
- In reply to: Kristian Köhntopp: "Re: [PHP-DEV] MySQL transactions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hello Kristian,
On 06-Jul-00 09:05:16, you wrote:
>Manuel Lemos wrote:
>> >The tables must be created as TYPE=BDB. These tables will not
>>
>> Isn't that enough to configure build MySQL with --with-berkeley-db ?
>> That's what I did.
>No, that is not enough. Only when the table type is set to BDB,
>the berkely db code is being used to manage the tables. For
Ok, I see there is a type option for the create table statement. I forced
it to be BDB and I can confirm now that transactions work in MySQL as it
passed all Metabase driver tests for:
- Rollback inserted table rows
- Commiting inserted table rows
- Commiting deleting rows
Notice that theses test do not verify concurrency safety because that
requires multiple scripts to run and attempt to access and change the same
tables.
>> >use the native MySQL tables, but go through the Sleepycat DB3
>> >support instead. It is highly unlikely that MySQL will have
>> >transactions on TYPE=ISAM, TYPE=MYISAM or TYPE=HEAP tables ever.
>>
>> I'm not sure about the impact of what you are saying, but a robust business
>> application requires a database that supports transactions, especially if
>> money is envolved.
>You can get very far with MySQL without transactions, but for
>some operations transactions are necessary. They are also slow.
Anybody tried to compare doing transactions with MySQL and other databases
to see how they perform?
>> It's not admissable to deal with somebody's money while
>> risking to get the values in the database be inconsistent
>> or corrupted by failed transactions that could not be
>> rolled back.
>I have seen some financial software (for example early versions
>of the Cybercash Cash Register) from the inside, and transactions
>are not going to save them, either. 1/2 :-) CCR may have improved
I don't know if that's what you mean, but sometimes single phase commit
transactions are not enough because a transaction may only be done when
commit suceeds in multiple sites that are controlled by more than one
database server. Multiple phase commit transaction support is required
but AFAIK only higher end DBMS support that.
>over time - I do not know current versions at all - but what I
>received back then (Version 2, in beta) was a chest of screws
>and parts (how do you translate "Eine Kiste Schrauben" into
>an appropriate english expressions). It was by no means a
>product, transactions or not. An overall design robustness
>is much more important than individual features of subproducts
>such an transactions in a database.
The ability to use database transactions is often part the robustness of
the product. If you can't use transactions when you need them, you can't
say your product is robust.
Regards,
Manuel Lemos
Web Programming Components using PHP Classes.
Look at: email protected>?subject=Re:%20[PHP-DEV]%20MySQL%20transactions&replyto=3015.225T533T10163942mlemos <email protected>">mlemos <email protected>">http://phpclasses.UpperDesign.com/?user=mlemos <email protected>
-- E-mail: mlemos <email protected> URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp ---- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe <email protected> For additional commands, e-mail: php-dev-help <email protected> To contact the list administrators, e-mail: php-list-admin <email protected>
- Next message: Manuel Lemos: "Re: [PHP-DEV] *crash* on try to find out how many nestinglevelsare allowed"
- Previous message: Andi Gutmans: "Re: [PHP-DEV] Extensions calling C++"
- In reply to: Kristian Köhntopp: "Re: [PHP-DEV] MySQL transactions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

