[keycloak-dev] KeycloakSession question

[Stan Silvert]

Besides needing to implement a way to make the in-memory copy, that 
would leave me with the same problem I have now.

If I write the copy to disk, I might overwrite changes from some other 
KeycloakSession.  Remember, I have to write the whole model to disk and 
my local model might be stale.  This is the problem I have today as 
every KeycloakSession has its own copy that was read from disk.

If I write from the master in-memory model, I need to wait for active 
sessions to end before I write it out to disk.  That's what I'm 
proposing to do.

On 4/10/2015 12:28 PM, Bill Burke wrote:
> Adapters are created per KeycloakSession too (RealmAdapter, etc.).  If a
> write method is called on the adapter, you know that underlying instance
> must be synced at commit time.
>
> So, here are the steps you should do:
>
> 1. Somebody accesses RealmModel
> 2. RealmAdapter is created, it delegates to shared in-memory model
> 3. If RealmAdapter write method is called copy in-memory model of
> RealmAdapter, make your changes within the copy
> 4. At commit, flush the changes to the RealmAdapter to main memory model
> and disk.
>
> If you want to get more consistency, add a version field to in-memory
> model, that way you can do "optimistic" concurrency and abort the sync
> if the version field is changed.  We should actually probably do this
> with our JPA model too.
>
> On 4/10/2015 11:55 AM, Stan Silvert wrote:
>> On 4/10/2015 10:28 AM, Bill Burke wrote:
>>> KeycloakSession is analogous to an EntityManager in JPA.  It only exists
>>> for the duration of the request.  What you'd want is for File-based
>>> storage to queue up writes and flush them when the KeycloakSession is
>>> committed.
>> That's basically what happens now.  The problem is that there is no
>> concept of individual writes.  Every time you write, you must write the
>> entire model.  With each KeycloakSession having its own copy of the
>> model, one KeycloakSession can overwrite the changes of another.
>>
>> If you use a single shared in-memory model, you have to wait until
>> everyone is done writing to it before you can save it to disk. That's
>> the scheme I outlined below.  It sounds like it will work since we know
>> that each KeycloakSession will end in a timely manner.
>>
>>> On 4/10/2015 9:15 AM, Stan Silvert wrote:
>>>> Is KeycloakSession always short-lived?
>>>>
>>>> If so, it might be relatively easy to make the JSON File based
>>>> persistence more robust and probably fix the cache tests that currently
>>>> fail with it.
>>>>
>>>> All KeycloakSessions would share the same in-memory model.  When a
>>>> KeycloakSession ends and requests to write the model to disk, all new
>>>> requests for access to the model are blocked.  When all active
>>>> KeycloakSessions are done, we write out the model and unblock the new
>>>> KeycloakSessions.
>>>>
>>>> But this only works if we can assume KeycloakSession is short-lived.
>>>> _______________________________________________
>>>> 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
>>