Although you haven't specified the underlying database, I assume it's either Oracle, PostgreSQL or MySQL since the behavior is the expected one.
With any DB that uses MVCC instead of two-phase locking (e.g. the default concurrency control mechanism in SQL Server), readers do not block writers and writer don not lock readers. For this reason, even if you acquire a
PESSIMISTIC_WRITE lock,
the exclusive lock will not prevent other transactions from reading the underlying locked rows.
For MVCC DBs, the row-level lock which is acquired either by a FOR UPDATE clause or by an UPDATE, prevents the dirty write phenomena. This way, other transactions are not allowed to write the same record, and they will simply block until the first transaction ends. Depending on the
current isolation level, after the first transaction commits, the second transaction update statement that was blocked can either succeed (READ_COMMITTED) or fail (REPEATABLE_READ or SERIALIZABLE) because otherwise a lost update phenomena will occur (this can happen with MySQL even on REPEATABLE_READ).