Hi Andrew
I could be wrong. Thought Kieren meant the new version:32 rolls back the
entire transaction(s) if a timeout occurs for the last transaction. ...and
therefore saveChanges will ensure all or none of the transactions will be
committed into database. So no partial save. I am using version 26, and
did not notice the issue. Could do a test later of the night.
"Incompatible change: As of MySQL 5.0.13, InnoDB rolls back only the
last statement on a transaction timeout. In MySQL 5.0.32, a new
option, --innodb_rollback_on_timeout, causes InnoDB to abort and roll
back the entire transaction if a transaction timeout occurs (the same
behavior as in MySQL 4.1)."
Terribly sorry if I got it the other way around. Thanks.
Cheers
Cheong Hee
----- Original Message -----
From: "Andrew Lindesay" <[EMAIL PROTECTED]>
To: "Cheong Hee (Datasonic)" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Tuesday, February 19, 2008 3:00 PM
Subject: Re: MySQL 5.0 - note
Hello Cheong;
The "typical" transaction behaviour would be for either all of a
transaction to be stored corrected in the database server or none of the
transaction would be stored. Kieren is describing a situation where some
of a transaction is stored and some is not stored so you can't be sure
what has been stored and what has not. Doesn't sound like a happy
situation.
cheers.
May be by default, you pay less, if you'd need to. MyISAM is cheaper..
Thanks Kieran for useful info, and thought by default MySQL should do
so. Is FrontBase do the same roll back if timeout?
___
Andrew Lindesay
technology : www.lindesay.co.nz
business : www.silvereye.co.nz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
