Bug #34092 | Falcon concurrent control does not work as document description. | ||
---|---|---|---|
Submitted: | 27 Jan 2008 18:39 | Modified: | 29 Jan 2008 15:42 |
Reporter: | Chris Wood | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Server: Falcon storage engine | Severity: | S2 (Serious) |
Version: | mysql-6.0.3-alpha-win32 | OS: | Windows |
Assigned to: | Kevin Lewis | CPU Architecture: | Any |
[27 Jan 2008 18:39]
Chris Wood
[27 Jan 2008 21:17]
Hakan Küçükyılmaz
Chris, which isolation level are you using? Please provide the output of: show variables like 'tx_isolation'; Best regards, Hakan
[28 Jan 2008 14:09]
Chris Wood
Hakan, Two sessions both use REPEATABLE-READ isolation level. mysql> show variables like 'tx_isolation'; +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | tx_isolation | REPEATABLE-READ | +---------------+-----------------+ 1 row in set (0.01 sec)
[28 Jan 2008 15:08]
Kevin Lewis
Chris, What you have discovered is the difference between falcon_consistent_read=ON and =OFF. This setting was added last fall to separate two ways in which Falcon can do repeatable-read isolation. The default setting is falcon_consistent_read=ON. In this mode, Falcon provides a consistent tead, regardless of the outcome of a transaction you might be waiting on. In this mode, the documentation is correct. The second transaction starts while the first is still active, and it needs to use a record that has a pending change, so it waits regardless of the falcon_consistent_read setting. If the first transaction rolled back, the second transaction will be able to succeed in both modes. But if the first transaction succeeds, and falcon_consistent_read=ON, the new record version is not visible. Consistent read requires that Falcon return 'Record has changed since last read'. But if falcon_consistent_read=OFF, Falcon will act more like InnoDB, and use the new version of that record. In this case, once the first transaction commits, there are no more reords visible 'where c1=1'. This is the way InnoDB repeatable-read works, so we added this ability. It allows better concurrency in that fewer transactions fail, but they are affected by other concurrent transactions and they are not always repeatable. They allow these kinds of phantom reads.
[28 Jan 2008 15:19]
Ann Harrison
Would you also check the falcon specific parameters? There's one (falcon_consistent_read that causes this behavior if it is set to false.
[29 Jan 2008 3:14]
Chris Wood
Kevin Lewis,Ann Harrison I use mysql-6.0.3-alpha-win32, and in this version falcon_consistent_read is not available. mysql> show variables like 'falcon_consistent_read'; Empty set (0.00 sec) Are there any way to set falcon not behave like innodb in this MySQL version?
[29 Jan 2008 4:36]
Kevin Lewis
Chris Wood, You are testing a version of Falcon that does repeatable read only in the InnoDB compatible way. Jim changed the original Falcon repeatable-read from a consistent read to this innoDB compatible method sometime last summer in order to gain performance with DBT2. It was that way until shortly after mysql-6.0.3-alpha, when I reactivated the consistent read method as the new default and introduced the falcon_consistent_read setting. See Bug#22151 for more detail. In order to test this, try the Falcon Feature Preview. http://forge.mysql.com/wiki/Falcon_Feature_Preview
[29 Jan 2008 15:10]
Chris Wood
Hello Kevin Lewis, I download mysql-6.0.4-alpha-2008-01-07-win32.zip, and it is ok. But I can not access Bug#22151(the page returns 'You do not have access to bug #22151.'), so could you paste that content here? Thanks.
[29 Jan 2008 15:42]
Kevin Lewis
Sorry, Chris. I made a typo! It is Bug#29151. The informative comments I mentioned wer on Nov 1 & 6. You will notice that this bug is still open because there remains some instance in which the innoDB compatability is not exactly right. But it is mostly there.