On 5/5/2015 2:29 PM, Marek Posolda wrote:
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?
Again, I fixed that. The problem is that there is a table lock deadlock.
JBoss, a division of Red Hat