I've done this before and it's a valid technique. It still has some edge cases that can bite you. First, you still have to make sure that you do all your reads and updates in a consistent order because otherwise you will deadlock. Second, and more important, you must use repeatable reads for this technique. Otherwise given my example of orders and order items, you can get really funny behavior. Say you have a function on class Order that recalculates totals with tax, shipping, etc. It's going to be based on the rows in the order items table. So you do your read of order row with FOR UPDATE, then read a list of items and do some calculations and update things. Then in the same transaction you read the order items again, except the user has now added another item to the cart. If adding items to the cart didn't lock the order with FOR UPDATE, that read would have gone through.

Also, locks using FOR UPDATE don't have explicit lock mechanics. You can't check if that row is locked. You can't easily control the timeout. I consider it a bandaid technique. Bandaids are great for small boo boos, but they don't work if you already have a codebase that is complex and does things in an inconsistent order.

Thanks for the extra detail; it's always good to hear of any gotchas. In my system a lot of what happens is effectively a single user operates on a subset of data that nobody else touches but I'll definitely to a named lock prototype before I go down any particular path.