I think you are referring to Concurrency. Check out the link to get started on understanding it, if that is what you are asking about. You will probably have to do a little more research depending on your back end and your specific situation. Again, if this is what you are looking for you may be particullary interested in pessimistic concurrency.

There are a lot of different ways to achieve this. You can use timestamps on your records. When you do an update you make sure that the id matches and the timestamp that your application pulled with the record matches.

To avoid having a user read a record that is uncommitted look at using sql hints in your queries.

one way to accomplish the task:
you will have to add a "lock" field to your table.

then you should write a stored procedure that will take some ID as a parameter, atomically select a row with NULL lock, update the row so that lock will contain the passed id and then return the value.

As long as the stored procedure is executed atomically (any other requests for the table will wait until this one is finished) every client calling this procedure will get another value that still had it's lock field empty. Once the value is returned client is confident that the row containing the value has its lock field set to some value an will not be returned.

After you do modifications you should update the row, writing the new value and setting the lock field to NULL, thus "unlocking" the row for future requests.