除非提交表单，否则如何锁定数据库中的ID

Question

I have one form that shows a unique id under which the form will be submitted. The unique id is- last unique id in DB+1

Now, when the form gets submitted in DB, it actually doesn't directly insert that unique id in db. It then dynamically checks the last unique id of db and then insert last id+1.

So, the situation may often come that what a user sees as his form id(that unique id), the form may not actually get submitted under that unique id because if somebody else(user2) in the meantime submit the form, then User1's form will be submitted under the unique id+2 value.

My question is, how to lock the id for the time duration from when the user opens the form and until submit it.

Please let me know, if the question is not clear to you. But this is a very tricky and important thing for large business application. Kindly advise me.

Answer 1

I see two options

• Show the ID after the insert is made, not before. What if the user cancels? You will waste a lot of IDs. OK, there are plenty but I can image how a DoS attack would look like.
• If you need the ID to give the user a reference ID for later contact with the support or such just create a different ID appart from the technical primary key. This ID can be calculated before an insert and also saves you trouble as technical IDs might change in migration scenarios.

Answer 2

Locking is not a good idea, especially for a large business application. All the other concurrent requests (people) will have to wait until the current user submits the form. Users will experience long response times, app server resources will saturate and the application will crash even with a very minimin load.

A preferable approach would be to inform the user of the id only after the form submit. It likely is not useful info for them beforehand.

Anyway, the exact implementation of the lock depends on your db but is something like: begin transaction select max(id) from foo [somehow increment id] [wait for user submit] insert into foo values (new_id) commit

But again, you should avoid adopting this approach