Skip to content

Handle concurrency issues better in specify #5337

@realVinayak

Description

@realVinayak

A copy-paste of issue: https://github.com/specify/specify-development/issues/19

  1. Workbench performs everything in a transaction. If this was alone by itself, this wouldn't have caused an issue.
  2. Subtle concurrency issues with trees can issues. For instance, workbench if uploads trees, then it causes issues with tree actions which involve node numbering (because we end up doing a select * where nodenumber = whatever for update, but since node numbers aren't indexed, it implictly locks all rows (this is still not a full table lock)
  3. If you make collection objects via the form, when workbench is uploading to collection objects, then autonumbering causes a write lock on collectionobject, collection, and other tables. This is very bad. form's lock is delayed by workbench, so form save doesn't happen (gets timed out). Plus, no body is able to use specify because a simple '/specify/' request causes a read request from collection table (which waits for the write request from collection from form to be granted)

See #5047.

Some raw ideas:

Make this accept two args: one for read and one for writes.

def lock_tables(*tables):

Make this return 2 sets, one for read and one for writes. Repetition isn't allowed, so if a table is in both, elevate it to a write (just remove it from read). Put all the discipline, collection, and uniqueness rule tables, and the scope_table in the read set (basically, everything we know we won't write to)

def get_tables_to_lock(collection, obj, field_names) -> Set[str]:

Metadata

Metadata

Assignees

No one assigned

    Labels

    1 - BugIncorrect behavior of the product4 - PerformanceIssues related to performance, concurrency, and optimization

    Type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions