> i dont think, that you are right. > are you really sure that you do not mean isolationlevel > 'serializable'. >
Uhm, err, yes - it is only such strict for 'serializable'. I messed it up :-) > by the way: > i got an answer some times ago from Elke Zabach: (perhaps > its still up to date?) > > "Usually they are not locked. But there exist kernel-versions > in which a row is selected, but updated by another transaction. > It then has to wait for the release of that > update/insert/delete-lock, i.e. > has to wait for the commit/rollback of the other transaction. > Then it will have a lock afterwards." > ... Yes, that is still valid. If you have a row locked in exclusive mode by some session (row_exclusive), and a select is waiting to read it, it will get that lock and keep it, e.g. consider the example Table ABC with A as integer and B as VARCHAR(20): | A | B | | -------------- | -------------------- | | 1 | AAA | | 2 | AAA | | 3 | AAA | SESSION 1: UPDATE ABC SET B = 'BBB' WHERE A = 2 SESSION 2: SELECT * FROM ABC Session 2 hangs until Session 1 has committed or rolled back, and has afterwards a row_share lock on the affected row number 2. Anyway, I fear there might be something with the python script you use for getting the content of LOCKSTATISTICS, as its conten looks a little bit in-plausible ... Regards Alexander Schr�der SAP DB, SAP Labs Berlin -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
