What to use instead of SQL Server Timestamp for opportunistic locking?

[Rob Roberts]

For handling opportunistic locking under MS SQL Server, I've always used a Timestamp column in my tables. Timestamps work great for this because they are guaranteed to be unique within the database. So before saving any changes to a row, I read the current value of the timestamp, and if it has changed since the user retrieved the row to start editing it, I display an error message saying that the row has been changed by another user.

How are people handling this with MySQL? It doesn't seem to have any unique timestamp or rowversion type. There is a timestamp data type, but its resolution is no finer than one second. If a MySQL timestamp was used for this type of opportunistic locking, there would be the possibility that a row could be retrieved and modified without the timestamp value changing. (Especially if the read/modify operation was performed by some kind of automated process.) And this would leave open the possibility that the changes could be inadvertently overwritten by another user.

How are others handling opportunistic locking?

Thanks in advance,
--Rob Roberts