Make a transaction between to pages.

can't you do something like display the form, let user edit and keep everything in memory (view state or session etc.) and while submitting, open one transaction, execute statements you wants and commit transaction if it is successful.

We don't want that 2 users can open the edition page of the same product. So we want that the row is locked.

Why manage it in the logical part if the database can do it? We assure that our data are consistent, by exemple if one time we got a webservice, ...

The structure of the database is fixed, and it's only for a educational goal.

Just becuase the database CAN do it, doesn't mean it is a good idea to let it.  For example, if you start a transaction, get data, wait for the user to edit the data, the rows (and potentially pages, extents, and ultimately the table) in which you retrieved are now LOCKED..meaning others cannot modify it.  In terms of concurrency, this is a nightmare.  The last thing you want to do is to allow a user to determine how long something is locked at the database level.  Adding a little extra code ensures that you're saving yourself from these headaches.

And if we flag the row, she is locked too.

And this isn't an option, the client asked exactly the comportment you describe.

but in that case, you will have control to unlock it, not client. you can change the flag by datetime stamp checking.

Well, I would tell the client it is a bad idea....that you can do it, but you advise against it.

The database has timeout too ;)

of course it does...most queries are going to timeout once you start opening connections and rely on the user to commit them.

So why use a logical timeout and not a database timeout?

Doing it logically through code, you're not going to get the errors and the locking that is going to come with trying to enforce through the database engine.