Repository navigation
Replies: 2 comments 4 replies
|
This raises the question - should components be stored inside a metadata or in a separate table? |
|
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. |
|
@sguilhen - with the latest changes the component behaves as a root entity in the JPA implementation, still looking on the logical layer it only serves "dumb" ComponentModel objects that don't allow for direct manipulation. This is IMHO is a mismatch. Still we could agree to keep it as is for now. As we now split the storage inside JPA to allow independent manipulation of the realm and the components, I wonder if we plan for any other storage to handle Realms (Infinispan?), should they split their storage into realm and components as well to avoid concurrency problems? |
|
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 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:
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. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Implementation of the
JpaRealmEntityin PR #10901 implementsJpaRootVersionedEntityfor optimistic locking.However, when running the testsuite with the JPA Map Realm storage enabled, a few tests fail with
OptmisticLockException. (see #11070). One of the tests,ComponentsTest, attempts to create components in multiple threads, which raises the question: Is it expected that a realm can be updated concurrently by multiple threads? If it is, should the entity still use optimistic locking and basically rely on clients retrying the operation in case of failures or should we simply not use optimistic locking for realms?Components are just a tiny part of a realm, if client apps are using multiple threads to update different realm areas, such as auth exectutions, auth flows, identity providers, required actions, etc, they are certainly going to hit the issue highlighted by the test.
All reactions