optimistic locking mechanics?

Piggybacking onto this, this suggests that in an optimistic scenario that one will alert the user who changed a record (between the read and update of another user at a CRUD web page form) of the alteration instead of being silent about it meaning that there will still be need to store who changed the record last at a database column (in my interpretation). To digress: My understanding of how one does pessimistic concurrency mechanics entails keeping a database column for who (user id) last "touched" the row in the database in question (even if only to read), a DateTime type column for when the "touching" started, and then possibly a boolean/bit type field for if a lock is on. If the last of these fields is skipped then I wonder if the DateTime field just becomes nullable to manage this sort of on/off state. Clearly, if the date is too old then any locking needs to be assumed to be old news, so maybe such checking negates the need for the DateTime to be nullable (or to have the boolean/bit column). You have to check anyways, right? I suppose the nullable state or the boolean/bit column could make checking faster.