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(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>