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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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.id
and correspondingclientSessionId
.MapUserSessionEntity
contains the following methods:On logical layer there are separate methods that are managing client sessions in the
UserSessionProvider
.MapUserSessionProvider
is 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.
JpaUserSessionEntity
doesn’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
->AuthenticationSession
orRealmEntity
->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
MapUserSessionEntity
should not containMap<String, String>
. The methods could look something like this:The implication of it could also be a possibility to make the
MapAuthenticatedClientSessionAdapter
class 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:
UserSessionEntity
that translates the operations done on client sessions into client transaction calls. For example, ifremoveAuthenticatedClientSession
is called on a user session the delegate should translate this to call on client session transaction:clientSessionsTx.delete(clientSessionId)
etc.Beta Was this translation helpful? Give feedback.
All reactions