> You may wish to look at locking the tables in question for this kind of
> thing to be done. It could be handled as a transation as well, but it
> would require more analysis of other parts of the system than just this
> presentation ordering to determine what things would need to happen to
> ensure that only the right changes get made.
>
> See http://dev.mysql.com/doc/refman/5.0/...-commands.html
> for information about both locking and transactions. Quote:
" ...
This is the default isolation level of InnoDB. SELECT ... FOR UPDATE,
SELECT ... LOCK IN SHARE MODE, UPDATE, and DELETE statements that use
a unique index with a unique search condition lock only the index
record found, not the gap before it. With other search conditions,
these operations employ next-key locking, locking the index range
scanned with next-key or gap locks, and block new insertions by other
users.
In consistent reads, there is an important difference from the READ
COMMITTED isolation level: All consistent reads within the same
transaction read the same snapshot established by the first read. This
convention means that if you issue several plain SELECT statements
within the same transaction, these SELECT statements are consistent
also with respect to each other.
...."
|
I'm already using transactions in most of the features supported by
this system, from what I've read in the documentation, only
transactions will solve my problems since by default, isolation level
is REPEATABLE READ, and if I understood it right all the SELECT's done
in one transaction will be done in the same snapshot.
Although I think I didn't quite understand the first paragraph does it
mean, that if all the statements are performed with transactions,
there will be no problems (caused by the multiuser-system) since the
index range will be locked and new insertions will be blocked.
Is this right? Can any one explain this to me?
Any help will be appreciated.