Jpa map storage - structure of entities #13229

vramik · 2022-07-20T15:13:22Z

vramik
Jul 20, 2022
Collaborator

There are few interfaces in jpa map store

JpaRootEntity - interface should represent an entity with jsonb colunm. There are methods for getting and updating entityVersion. Also method for obtaining currentSchemaVersion
JpaRootVersionedEntity - extends JpaRootEntity and adds optimistic locking feature for the entity
JpaChildEntity - should represent child entity (has R getParent() method) and also serves in both JpaOptimisticLockingListener and JpaEntityVersionListener.

With implementation of user jpa store there has been added few entities which somewhat collides in terms of above.

JpaUserConsentEntity, JpaUserFederatedIdentityEntity implements JpaChildEntity (so it affects locking of its parent entity JpaUserEntity within JpaOptimisticLockingListener) and also contains jsonb column (which is not taken into an account when JpaEntityVersionListener tries to update the entity version).

Also with auth session implementation: JpaAuthenticationSessionEntity is technically child entity of JpaRootAuthenticationSessionEntity but doesn't implement JpaChildEntity, so nothing happens within JpaOptimisticLockingListener.

Any thouths?

Should we e.g. create new interface for entities with jsonb column and leave parent-child relationship as is? Or can we mark some entities as both parent and child?

ahus1 · 2022-07-22T10:20:49Z

ahus1
Jul 22, 2022
Collaborator

Hi @vramik - thanks for starting this discussion. Here some thoughts, some are not answers, yet:

The idea of parent/child, where a modification in the child locks the parent, came from the attributes that many Keycloak entities have. I argued that a change in one attributes of a user depends on the state of the parent entity (the user) and all other attributes of that user. Modifying two attributes at the same time, or modifying an attribute and the user at the same time could lead to a strange state. In fact the UI will save a user and its attributes as one REST call.
For the realms, we argued that the components can be added and removed independently of each other to a realm, so a component doesn't implement the JpaChildEntity. This works similarly for the composite roles, where you can add a composite role to a role without locking the parent role, thereby doing that concurrently.

You have been asking about JpaUserConsentEntity and JpaUserFederatedIdentityEntity if they should implement JpaChildEntity. I feel that I don't know enough yet how that data changes in transactions. Locking the parent entity might be the safe thing to do, as long as it doesn't lead to extensive locking. Maybe you can add more information to the discussion.

Looking at the JpaEntityVersionListener, I agree that this one should operate on any entity that has a JSON field. While it traverses the tree from the child upwards to the parent, it should call updateEntityVersion on all entities it finds. This calls for a new interface IMHO.

Regarding the AuthSession implementations: Let me recap what I know about the relation of JpaRootAuthenticationSessionEntity and JpaAuthenticationSessionEntity. The root one encapsulates a login from a browser by a user, and the other one represents one tab of that browser. When logging in / interacting in one tab, it would be ok to block also the other tabs as this makes logging in / reasoning about the state a lot simpler. Previously I remember there were some problems with nested transactions that should be gone after the latest changes. So I'd be +1 to make the non-root session a child of the root session.

I'd may even go so far to advocate for pessimistically locking the root session to make a concurrent interaction in another tab wait for the other tab to complete. When doing this, I'd be a bit hesitant, as we're also locking user sessions already. If there are different areas of the code that lock those two objects pessimistically in a different order, this could lead to deadlocks. Keeping the optimistic locking would lead to optimistic locking exceptions. So let's be cautious here.

0 replies

Navigation Menu

Repository navigation

Jpa map storage - structure of entities #13229

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Select a reply

Uh oh!

Jpa map storage - structure of entities #13229

Uh oh!

Uh oh!

vramik Jul 20, 2022 Collaborator

Replies: 1 comment

Uh oh!

Uh oh!

ahus1 Jul 22, 2022 Collaborator

vramik
Jul 20, 2022
Collaborator

ahus1
Jul 22, 2022
Collaborator