You have something that is called optimistic locking. But it doesnt, per say, solve your problem of 'reporting' that the row is locked. For most cases reporting is usless, but it can be solved programaticly.
That locking is kinda 'fun' depend if you are making desktop app, or web one, but mostly it is solved with using of extra column (timestamp) and lock a row for a period of time.
I made one project where i reported a user a row is locked, and i solved it with 2 fields (start time, end time) due i wanted to give variable amount of time to the person to update row.
sample:
query: select a, b, c, d, start_time, end_time FROM table
Program : if ((datetime.now()-start time > 1min) or (end_time <> null))
{
update table
SET start_time = datetime.now()
set end_time = null
where A = a and B = b and C= c and D = d, and START_TIME = start_time
--big caps is current value, small caps value from last select ( and that is OPTIMISTIC concurency).
}
else
{
messagebox.show ("You suck, cant be changed") --personal touch :-)
}
when you update row, dont forget to place end_time.
OFC, check for time, within update is possible
Edit: i got that idea from row_scn in oracle, so it isnt anything revolutionary