> 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/maxdb?unsub=gcdm-maxdb@xxxxxxxxxxx
|
