[keycloak-dev] OOTB session-jpa not viable?

[Marek Posolda]

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)

As mentioned in private mail, I see this possible solutions:

1) When parent broker receives logout request from child broker, the 
parent shouldn't send another backchannel logout request to the same 
child broker again.

2) Add the flag to UserSession before it sends backchannel logout 
request to parent broker. When parent broker sends logout request back 
to the child, the child broker will see the flag on UserSession and it 
won't try to remove it.

It looks that (2) is better as it will work with 3rd party parent 
brokers as well. Basically (1) requires handling the situation on parent 
broker, but with 3rd party parent brokers, we don't have control if they 
implement this.

Marek

On 5.5.2015 18:32, Bill Burke wrote:
> In tracking down a bug I found that in certain cases the database (H2?)
> that comes with Wildfly will perform table-level locks.  It definitely
> does a table lock in transactions that require inserts.  Not sure if it
> happens on regular row updates.
>
> Makes me feel like we have been really lucky altogether that we haven't
> run into problems so far.