On 5.5.2015 19:48, Bill Burke wrote:
On 5/5/2015 1:31 PM, Marek Posolda wrote:
> Unfortunately the test is failing on all RDBMS, not just H2 :-(
>
> I did debugging with MySQL yesterday and saw that UserSessionEntity was
> successfully deleted in chained backchannel logout request, but
> transaction in original request failed due to foreign key
> (UserSessionNote couldn't be added to already deleted UserSession)
>
I have fixed this problem in my local repo. For OIDC I was checking
the state of the UserSession to see if it was in a LOGGING_OUT state.
If it was, I wouldn't delete the user session. I forgot to do this
for SAML...
Unfortunately, once I fixed this problem I ran into table locks:
1. Application initiates logout
2. Keycloak receives app request, adds a UserSession note (this locks
the UserSessionEntity table)
3. In same request, keycloak invokes a backchannel broker logout.
Note, this request has not committed the current KeycloakSession and
the UserSEssionEntity table is still locked
4. Keycloak receives the broker backchannel logout request. Tries to
delete the broker's UserSession which tries to delete all
UserSessionNotes. UserSessionEntity table is already locked...BANG!
Deadlock! fail!
Table locks scare the shit out of me. They are a nightmare to fix and
often can't be fixed without massive rearchitecture.
In this situation though I believe I can fix the problem by committing
the transaction in Step #3 before invoking the backchannel broker
logout request. Then, restarting the session thereafter.
Looks like a workaround, but hopefully should help to avoid these issues...
Still I wonder if it couldn't be handled in step 4 ? When Keycloak
receives broker backchannel logout request and it knows that UserSession
is already in LOGGING_OUT state, it shouldn't try to delete it? This
UserSession will be deleted later in the original logout request from
application once it finishes backchannel request. Or maybe I don't
understand it properly?
Marek