Concurrency - optimistic or pessimistic?

I’ve been looking to see how Frappe/ERPNext manages ‘concurrency’ in order to prevent more than one user from working on the same document at the same time. So far, I’ve not found anything.

A specific example might be where several users manage sales orders containing ‘drop ship’ items that need to be purchased. Presumably there is a list of these orders and it would be possible for multiple users to share the list. What happens if two users choose the same order to process? How does ERPNext prevent two purchases for the same item from being created?

Is there a table that contains items currently being edited or are concurrency problems only detected when an update is ‘saved’ and the date/time modified in the database is ‘after’ the most recent value that was retrieved?

At UI level, if two users are working on the same document, you get a non-intrusive message that pops up saying that User 1 is working on this document.

If you want to prevent anything functionally in the system based on your business requirement, there are custom validations you can do, like to not allow creation of two purchases from the same sales order etc.

At database level, InnoDB by default I think is set to REPEATABLE READ and row level locking to enforce ACID properties.

1 Like

Thank you. If the UI is already aware of the fact that more than one person is working on - or wanting to work on - a document then the most difficult part has already been addressed. Adding additional logic to areas where a more aggressive message or complete blocking is warranted shouldn’t be too difficult.

For the curious here are some readings:

https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html

https://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_file_format

1 Like