Bug #35631 | mgmapi reports abort on a unique index mix | ||
---|---|---|---|
Submitted: | 28 Mar 2008 7:55 | Modified: | 4 Nov 2008 23:16 |
Reporter: | Monty Taylor | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | MySQL Cluster: NDB API | Severity: | S3 (Non-critical) |
Version: | mysql-5.1-telco-6.3 | OS: | Any |
Assigned to: | Assigned Account | CPU Architecture: | Any |
Tags: | 6.3.17 |
[28 Mar 2008 7:55]
Monty Taylor
[4 Nov 2008 23:16]
Gustaf Thorslund
Verified using Cluster 6.3.17, current ndb-tools using bzr and: sture% ./get_ndb_status -v -c localhost -f foo 2 trans:0 read:0 write:0 commit:0 abort:0 range:0 scan:0 pk:0 2 trans:1 read:1 write:0 commit:0 abort:1 range:0 scan:0 pk:0 2 trans:0 read:0 write:0 commit:0 abort:0 range:0 scan:0 pk:0 2 trans:1 read:1 write:0 commit:0 abort:1 range:0 scan:0 pk:0 2 trans:0 read:0 write:0 commit:0 abort:0 range:0 scan:0 pk:0 ## run the select twice, first after the first line showed up and ## second time after the third line was output. sture% cat foo Trans_count:2 Read_count:2 Commit_count:0 Scan_count:0 Simple_read_count:0 Write_count:0 Attrinfo_count:2 Conc_op_count:0 Abort_count:2 Range_scan_count:0 Operations:2 TotalDataMemoryUsed:262144 TotalDataMemoryTotal:83886080 TotalDataPagesUsed:8 TotalDataPagesTotal:2560 TotalDataBlocks:249 TotalIndexMemoryUsed:114688 TotalIndexMemoryTotal:19136512 TotalIndexPagesUsed:14 TotalIndexPagesTotal:2336 TotalIndexBlocks:248 DataMemoryUsed2:262144 DataMemoryTotal2:83886080 DataPagesUsed2:8 DataPagesTotal2:2560 DataBlocks2:249 IndexMemoryUsed2:114688 IndexMemoryTotal2:19136512 IndexPagesUsed2:14 IndexPagesTotal2:2336 IndexBlocks2:248 So two aborted transactions are reported in this case.
[1 Jul 2009 14:58]
Frazer Clement
What appears to be happening is that the code in ha_ndbcluster::external_lock() which unlocks the 'external lock' is calling close_transaction(). As the transaction has 'state' in the kernel this results in the transaction being rolled back. For a normal, autocommited PK read (e.g. select * from t1 where x=10;), a 'Simple Read' is used which leaves no kernel state and does not need a transaction rollback. If a PK read with a lock is used (e.g. select * from t1 where x=10 for update;), the PK read does not use a simple read, and when the statement ends, the transaction is rolled back. Perhaps ha_ndbcluster::external_lock() should be changed to commit the transaction instead of just closing it in these cases?