I noticed the other day that the ModelCom locking behavior seems completely independent of the locking behavior of the dataset that may underlie a Model. I’m a little worried about that with the advent of DatasetGraphInMemory, because I think the “ergonomics” could be confusing. I have a test case up here:
https://gist.github.com/ajs6f/3e87cd6f78ec3b4e27a1 The problem is that when used without transactions, DatasetGraphInMemory tries to “do what the user meant” by auto-wrapping ::add or ::delete operations in transactions. But this leads to a case where a thread can get a model from a DatasetGraphInMemory-backed dataset, acquire the write lock for that model with no trouble, but then block trying to add or delete anything from it because the mutation is blocked by some other thread elsewhere that has the dataset lock. What would seem less surprising to me would be for the first thread to block waiting to get the model write lock. Does this seem too obscure? Is it worth trying to think about how ModelCom could respect the locking of an underlying Dataset, if one exists? --- A. Soroka The University of Virginia Library
