[keycloak-dev] KeycloakSession question

[Stan Silvert]

On 4/13/2015 2:02 AM, Stian Thorgersen wrote:
> As I've proposed before DefaultFileConnectionProviderFactory should have a ReadWriteLock. DefaultFileConnectionProvider should get a read lock. Then there should be a background thread that writes the changes, this should get a write lock. Simple and efficient.
Walk me through this then.  What are you locking on?  The in-memory 
model or the file?  What is the step-by-step process?

I don't see how this is different from my proposal except that you are 
using a background thread.  But I might not be fully understanding what 
you want to do.

BTW, I'm not actively working on this.  But if I get a little spare time 
I'd like to try something that would fix the cache tests and I think 
this might do it.
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 10 April, 2015 6:50:17 PM
>> Subject: Re: [keycloak-dev] KeycloakSession question
>>
>> 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
>>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>