Pessimistic and optimistic Concurrency (Lock versus Feedback)

Question

I am creating an application with the following criteria:

• work items: items that need to be manually processed over the Internet by users (short one page)
• Multiple Work Item Users
• Each user has a work item queue
• There is a search that allows users to browse “work items” and assign “work items” to their queues
• Users can take “work items” from other people's queues, assigning them to themselves

Note: work items only work once. This is not a wiki page, it is rather a corresponding exercise that should be performed by only one user. After the "work item" will work, it will disappear from the system (except for some audit / reporting), which is somewhat reminiscent of a bug tracking system

Which option do you think is better? Can you provide any major applications that support your opinion?

Option 1:

• When user A views or operates a work item, the work item is blocked.
• When other users go to the "work item" after user A opens the "work item", they can only see the "work item". They cannot write.
• The lock expires after n minutes, after which another user can block the "work item".

Option 2:

• Any user can pull out a "work item" without locking it.
• If user A works with the "work item" by submitting the form, and user B works with the same "work item", then the work of user A will affect the database, and user B will be informed that their changes have not been accepted affect because another user has changed the "work item".

I personally like option 2. Thoughts are asking?

Answer 1

It sounds like you are speaking pessimistic verses of optimistic concurrency.

Both are widely used, I personally think that optimistic concurrency is easier to handle, but it will depend on your own requirements and usage. If changes (and potential conflicts) are common, then a pessimistic concurrency control may be appropriate; if not, an optimistic concurrency will be faster and easier.

Let me know if you want to see code examples using the RowVersion data type in SQL Server (this is what I am currently using), it is pretty simple though:

• All tables include a RowVersion column.
• All SELECT queries include this column (for data that is subject to change)
• All UPDATE or DELETE queries include WHERE RowVersion = @RowVersion. This is the optimistic part, if 0 rows are returned, someone else touched the row, the update does not occur, so let the user know about it. NOTE. If the row has been updated, you must also return a new value for RowVersion. This also applies to INSERT queries, similar to returning the identity column identifier after insertion.

Answer 2

I don’t know how to describe the form in simple terms, but this is not a community of the page, this is a one-time thing. Hypothetically, for example, a user to match the name John DOEE to one of the next John Doe John Doe he worked, editing is completed. In our case, we would not need to just

Given this comment, I would go with option 1. Given that these changes are only time changes, there is no benefit to allowing several people to work with the same changes. You are wasting time on a 2nd person.

Answer 3

I personally will send with option 2 - plus, if applicable (for example, these changes are on a longer text), the user B is responsible for combining the changes. Give B a tool for this.