Re: MySQL transactions

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: http://phpclasses.UpperDesign.com/?user=mlemos@acm.org -- E-mail: mlemos@acm.org URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp --