Repository navigation
Replies: 2 comments 1 reply
|
Thanks for the write-up, @mhajas and @vramik! The whole thing gets a BIG +1 from me, including the introduction of the delegate in HotRod to allow for different transactions in that particular implementation. I think all proposed changes have been carefully considered here and it will make this relationship consistent with other relationships we currently have in the map storage. |
0 replies
|
It might also be possible to have one config only for both user and client session. As a result we may be able to modify |
1 reply
|
Sure, if we remove client session transaction from the provider it no longer makes sense to have two options. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Co-authored by: @vramik
Current state
Currently, there are two separate transactions, one for the user sessions and the other for client sessions. There is one-to-many relationship between user sessions and client sessions. Each storage implementation is expected to automatically remove child entities on parent entity removal.
On the physical layer, there is a
Map<String, String>in the user session entity that storesclient.idand correspondingclientSessionId.MapUserSessionEntitycontains the following methods:On logical layer there are separate methods that are managing client sessions in the
UserSessionProvider.MapUserSessionProvideris implemented in a way that it first creates client session entity usingclientSessionTx.create, then adds it to the user session viauserSessionEntity.setAuthenticatedClientSession(String clientUUID, String clientSessionId).Problem statement
In the JPA implementation to be able to model one-to-many relationship, it’s required to have access to the child entity object when it’s added to the parent collection.
JpaUserSessionEntitydoesn’t have access to theJpaClientSessionEntity. We’d need to introduce the entity manager into the entity itself to be able to load the object via its id. It’s not a nice solution.On the logical layer handling of nested AuthenticatedClientSession entity is inconsistent with other similar use-cases, for example,
RootAuthenticationSession->AuthenticationSessionorRealmEntity->Components. The reason for this distinction is given by the legacy Infinispan implementation where there was a performance issue when updating one client session entity meant callingput(UserSessionEntity)which was causing network overhead.Proposed solution
Logical layer
MapUserSessionProvider; changes to client sessions should be handled by user session transaction only.MapUserSessionProvider(may be postponed for later as legacy store still needs them)Physical layer
MapUserSessionEntityshould not containMap<String, String>. The methods could look something like this:The implication of it could also be a possibility to make the
MapAuthenticatedClientSessionAdapterclass non-abstract.HotRod changes
The tricky part is solving the performance issue for HotRod that would be basically reintroduced by the changes mentioned above. While for JPA implementation the one-to-many relationship is handled seamlessly there is nothing like this for HotRod. The implementation of HotRod UserSession storage/transaction would need to handle this relationship manually.
Ideas for HotRod:
UserSessionEntitythat translates the operations done on client sessions into client transaction calls. For example, ifremoveAuthenticatedClientSessionis called on a user session the delegate should translate this to call on client session transaction:clientSessionsTx.delete(clientSessionId)etc.All reactions