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

[Leonardo Loch Zanivan]

It's a common behavior for tables without primary keys.
The database lock all table on insert/update/delete.

I looked in my postgresql keycloak database and found alot of tables
without PK:
composite_role, databasechangelog, fed_providers, realm_application,
realm_default_roles

Please add PK in all tables, in relationship tables manytomany add a
composite PK (embedded id).

On Tue, May 5, 2015 at 2:31 PM Marek Posolda <mposolda at redhat.com> 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)
>
> 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.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150505/bb01f57e/attachment.html