[keycloak-dev] UserSessions support for cross-dc

Marek Posolda mposolda at redhat.com
Fri Jul 28 09:40:00 EDT 2017

Hmm, maybe yes. I don't know.

The question is, if they have same requirements like us? We have lots of 
backchannel requests, so we want to support the usecase, when same 
userSession is read and concurrently updated from multiple datacenters 
without the risk of write skews (lost updates).

Wildfly can probably rely much more on sticky sessions. I've checked 
that they have the documented option to add remoteStore to the 
infinispan cache. This is useful if they have sticky sessions and 2nd 
datacenter is used just as a backup in case that 1st datacenter becomes 
unavailable. It doesn't provide same level of consistency like us 
(prevention of write skews when concurrent update from both DCs happen), 
but likely sufficient with sticky sessions.

Hopefully we can also have an option to relax on consistency in favor of 
performance, once we will have sticky session support for backchannel 


On 27/07/17 19:10, Bill Burke wrote:
> Don't want to create more work for us, but, wouldn't this UserSession
> cross-DC approach be applicable to any http session data?  Maybe its an
> approach that should be ported to generically work in Wildfly for all
> servlet-based apps.
> On 7/27/17 8:25 AM, Marek Posolda wrote:
>> I've sent PR https://github.com/keycloak/keycloak/pull/4357 for subject.
>> It adds cross-dc support for userSessions, so that if you write
>> userSession "abc" in DC1, you will be able to read it in DC2 and viceversa.
>> Among cross-dc, it also provides the solution for lost updates (write
>> skew) issues where 2 threads on different cluster nodes (or in different
>> data-centers) updates same userSession. They both read the userSession
>> in same state and then both update it, but 2nd update will overwrite the
>> 1st one, which was committed first. I've used the pattern based on
>> tracking changes (events) and infinispan atomic-replace operation
>> described in the earlier mail:
>> http://lists.jboss.org/pipermail/keycloak-dev/2017-May/009347.html
>> So there was some refactoring of InfinispanUserSessionProvider to
>> support the event-based approach. One difference from the previous
>> proposal was, that events are not sent between data-centers but instead
>> userSession entities are directly written to remoteCache itself -
>> however the writes are still protected to avoid write skew issues. The
>> reason is, that with multiple datacenters, it can happen that
>> datacenters lost the network connection between each other (split
>> brain). Infinispan has some ways to restore from this state and sync the
>> entities after network connection is fixed. With the entities directly
>> in the cache, this should be easier to achieve then the case when the
>> remoteCache is used just as an event bus to send "changes" among
>> datacenters.
>> There is still lots of work for the cross-dc support, but hopefully it's
>> another step forward :)
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

More information about the keycloak-dev mailing list