[keycloak-dev] Keycloak with CockroachDB

[Pedro Igor Silva]

Interesting, didn't know about CockroachDB.

It seems your arguments and requirements to support this database are based
on its cloud-native nature and capabilities.

I think I understand some of the reasons behind this proposal. But how much
it adds to Keycloak architecture that could justify the changes/efforts you
mentioned considering that, even with current limitation of a single master
database, we do hava a cache layer on top of the database already managing
clustering and enabling cloud deployment ?

Regard.
Pedro Igor


Em sex, 2 de nov de 2018 05:58, Poiffaut Romain <romain.poiffaut at elca.ch
escreveu:

> Hello,
>
> For the Cloudtrust project (https://github.com/cloudtrust), I have
> investigated the feasibility of supporting CockroachDB in Keycloak.
>
> I have created a fork based on Keycloak 3.4.3 (it was the latest version
> when I started on this) working with CockroachDB 2.0.2. It is now working
> with this DB, and passes all unit tests. Some resilience tests have also
> been performed to validate the whole integration.
> Address of the repo :
> https://github.com/cloudtrust/keycloak/tree/cockroach-db
>
> For those who might be interested, here are some details:
>
> CockroachDB is a multi-master SQL database designed to run in the cloud
> and being resilient to failures (https://www.cockroachlabs.com/).
> This database has a lot of very interesting properties such as being
> lockless, distributed and supporting serializable isolation.
> CockroachDB introduces the notion of SAVEPOINT. As this DB is lockless, a
> transaction may fail due to a concurrent transaction. In such case, we can
> rollback to the SAVEPOINT and retry the transaction. Retrying transactions
> has the benefit of increasing their priority each time they are retried,
> thus increasing their likelihood to succeed. (More detailed information are
> available in their very good documentation (e.g.
> https://www.cockroachlabs.com/docs/stable/transactions.html#client-side-transaction-retries,
>
> https://www.cockroachlabs.com/blog/how-cockroachdb-distributes-atomic-transactions/,
>
> https://www.cockroachlabs.com/blog/serializable-lockless-distributed-isolation-cockroachdb/
> ))
>
> So even if CockroachDB uses PostgreSQL driver to communicate with the DB,
> one of the challenges was to add an automatic transaction retry mechanism
> with the smallest impact on Keycloak.
> Thanks to the architecture of Keycloak, this mechanism can be added in
> KeycloakSessionServletFilter with a very limited impact.
>
> A second challenge is due to the rollbackOnly mechanism implemented in
> Keycloak and Hibernate: after a rollback, a transaction cannot be used
> anymore.
> The retry operation must be performed in the same transaction to increase
> its priority.
> Thus the rollbackOnly mechanism is disabled/bypassed in order to keep the
> transaction active even after a rollback is issued.
> As suggested by CockroachDB, we replace the default Hibernate transaction
> coordinator class to a custom one (
> https://github.com/cockroachdb/hibernate-savepoint-fix).
> Moreover, we mainly modify JpaKeycloakTransaction so that if the
> transaction fails to commit due to retryable transaction error, we disable
> the rollbackOnly mechansim to able to retry the transaction.
>
> CockroachDB does not support addition of some constraints (e.g. primary
> keys) after table creation.
> To circumvent this limitation, we can create a new table, migrate the
> data, delete the old table, rename the new table with the correct name.
> As CockroachDb was not supported by Keycloak until now, we didn’t adapt
> all existing liquibase scripts. We decided to create a new liquibase script
> which creates the whole database schema for the current version.
> This current limitation is being discussed and will be fixed in future
> release (https://github.com/cockroachdb/cockroach/issues/19141).
>
> Some tests have also been slightly adapted to support SERIALIZABLE
> isolation, so other DBs configured with such level can also benefit from
> this adaptation (i.e. PostgreSQL)
>
> These challenges have been solved and our forked version of Keycloak is
> now compatible with CockroachDB, but it currently is at the cost of
> breaking the usage of standard databases.
> Our company is really interested to add the support of this DB into
> Keycloak and to provide it to the community.
> The next steps now would be to migrate our fork to the latest version of
> Keycloak and add the support of this DB without breaking support of the
> others and we would be happy to discuss it.
>
>
> Cheers,
> Romain Poiffaut
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev