How does optimistic locking actually enforce re-read/update?
The basic technique is quite straightforward.  When you read the record you take a note of the version or timestamp column, e.g.

Select FooID
      ,Foo
      ,Bar
      ,TS      -- timestamp
  from Foobar
 where FooID = @FooID


When you go to write out the record you filter the write by the timestamp/version so that the write writes nothing if the timestamp/version has changed.  This makes the write atomic, e.g.

update Foo
   set Foo = @foo
      ,Bar = @bar
      ,TS = @timestamp  
 where FooID = @FooID
   and ts = @timestamp

select @row_count = @@rowcount  -- specific to t-sql, but this is a system variable
                                -- that holds the number of rows affected by the
if @@rowcount = 0               -- most recent operation.  Other DBMS platforms do
    [deal with outdated record] -- this differently.


This allows an application to do the update without holding locks open.  This is necessary
for n-tier systems working through a connection pool, and prevents a class of deadlocks 
that used to be common on two-tier client-server systems.

There is nothing enforced in the database about this.  It's all done explicitly by the application.