Is the realm-components relationship special when compared to the other realm related entities? I mean, in theory if you try to update flows, executions, required actions, etc using multiple threads you should also see a similar situation, but only components are tested for concurrency.

If the answer is yes, then we probably should have the components in a separate table.

Yes, the components are in general mutually independent and in general store mutually unrelated things: amongst components, there are realm keys, storage configuration, user profile configuration etc. Thus they may change more often than the other realm-related entities and independently of each other.

What do you mean by "dumb" objects that don't allow for direct manipulation? We have endpoints that allow for components to be created/updated/queried, so these are accessible externally. In fact the test that resulted in the OptimisticLockException is using these endpoints for manipulating components in parallel.

As for the other storages, what type of concurrency problems do you envision if they don't follow the same split pattern?

With "dumb" I had the following picture in mind:

• on a RealmModel, each method you call will have the change persisted at the end of the transaction, and it contains real logic.
• on a ComponentModel, the changes there will only be persisted when you call a method on realm, for example addComponentModel() or updateComponent()

I wasn't sure if the components are can be manipulated via their own endpoints; good to hear that this is possible. This is a +1 for making them root entities.

The concurrency problems I would envision for other stores if they don't follow the split pattern: if the implement optimistic locking, they would have optimistic lock exceptions. If the don't implement optimistic locking, the might incur lost updates.