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(a)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-t...,
https://www.cockroachlabs.com/blog/how-cockroachdb-distributes-atomic-tra...,
https://www.cockroachlabs.com/blog/serializable-lockless-distributed-isol...
))
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev