From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Tuesday, 8 July, 2014 1:17:17 PM Subject: Re: [keycloak-dev] Hybrid store committed On 7/8/2014 7:10 AM, Stian Thorgersen wrote: > I've committed the hybrid store including jpa store implementations. It's > enabled by default for the testsuite and the server, using jpa for realms > and users, and mem for sessions. > > By default the JPA stores all use the same persistence-unit, but it's > possible to split into multiple persistence-units and configure through > keycloak-server.json if someone wants to for example store realms in one > db and users in another. > > Remaining work includes: > > * Mongo stores > * Updates to Keycloak session - remove model methods and add an enlist > transaction feature for providers > * EntityManager and Mongo connection providers - I'm going to add providers > for retrieving EntityManager instances and Mongo clients. The main reason > for this is so that multiple stores can share the same > connection/transaction when possible My memory is hazy, but I think there is some automatic session management that EMF is supposed to do. So I don't think you need keycloak providers for EM creation. I'll have to look into it.

> * Delete JPA and Mongo model providers > * Update tests > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Tuesday, 8 July, 2014 3:00:46 PM Subject: Re: [keycloak-dev] Hybrid store committed On 7/8/2014 8:37 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: keycloak-dev(a)lists.jboss.org >> Sent: Tuesday, 8 July, 2014 1:17:17 PM >> Subject: Re: [keycloak-dev] Hybrid store committed >> >> >> >> On 7/8/2014 7:10 AM, Stian Thorgersen wrote: >>> I've committed the hybrid store including jpa store implementations. It's >>> enabled by default for the testsuite and the server, using jpa for realms >>> and users, and mem for sessions. >>> >>> By default the JPA stores all use the same persistence-unit, but it's >>> possible to split into multiple persistence-units and configure through >>> keycloak-server.json if someone wants to for example store realms in one >>> db and users in another. >>> >>> Remaining work includes: >>> >>> * Mongo stores >>> * Updates to Keycloak session - remove model methods and add an enlist >>> transaction feature for providers >>> * EntityManager and Mongo connection providers - I'm going to add >>> providers >>> for retrieving EntityManager instances and Mongo clients. The main reason >>> for this is so that multiple stores can share the same >>> connection/transaction when possible >> >> My memory is hazy, but I think there is some automatic session >> management that EMF is supposed to do. So I don't think you need >> keycloak providers for EM creation. I'll have to look into it. > > It may share the connection, but it's not going to share the transaction. > With the EM provider we can have a single transaction enlisted with the > KeycloakSession. At the moment you could end up with 4 transactions > (realms, users, sessions and audit) for a single request! > Are you sure it doesn't share the same transaction? It definitely does for JTA. Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

On 8.7.2014 16:12, Stian Thorgersen wrote: > If we used beans and container managed transactions then it might do > that. It may also just create multiple transactions and do a 2PC. But, > we don't, we start/commit our own transactions in Hibernate, and at > the moment we explicitly create multiple transactions. > > Before I'll start this I'll check what happens. I'm sure I can > relatively easily add some debug statements for when jdbc connections > and transactions are created. > > It may also be better for us to create a UserTransaction and have the > EM's enlist with that, instead of managing our own. That way we would > get proper 2PC when its supported. That may be a bit overkill though, > as I don't think we'd often want to update multiple databases at the > same time. +1 to use UserTransaction and JTA. I think earlier or later we may need to support 2PC anyway. Also AFAIK with JTA the jdbc connection is created "lazily" with Hibernate. In details if "hibernate.current_session_context_class" is "thread" (which is by default) then new JDBC connection is always opened when calling "hibernateSession.getTransaction().begin()" . But when "hibernate.current_session_context_class" is "jta" it retrieves JDBC connection lazily when DB call is needed by Hibernate. At least, last time I used this, it behaved this way. I used plain hibernate API though (not JPA EntityManager), but I don't think that the behaviour is different with JPA. With respect to the fact that we have caching layer, there may be many HTTP requests, which won't need to open JDBC connection, which might be nice performance gain IMO.

At some point we'll probably have to run on a trimmed down WildFly (no JavaEE stuff). Not sure if the transaction manager would still be there though. ----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Marek Posolda" <mposolda(a)redhat.com&gt;, "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Tuesday, 8 July, 2014 4:01:18 PM > Subject: Re: [keycloak-dev] Hybrid store committed > > > > On 7/8/2014 10:46 AM, Marek Posolda wrote: >> On 8.7.2014 16:12, Stian Thorgersen wrote: >>> If we used beans and container managed transactions then it might do >>> that. It may also just create multiple transactions and do a 2PC. But, >>> we don't, we start/commit our own transactions in Hibernate, and at >>> the moment we explicitly create multiple transactions. >>> >>> Before I'll start this I'll check what happens. I'm sure I can >>> relatively easily add some debug statements for when jdbc connections >>> and transactions are created. >>> >>> It may also be better for us to create a UserTransaction and have the >>> EM's enlist with that, instead of managing our own. That way we would >>> get proper 2PC when its supported. That may be a bit overkill though, >>> as I don't think we'd often want to update multiple databases at the >>> same time. >> +1 to use UserTransaction and JTA. I think earlier or later we may need >> to support 2PC anyway. Also AFAIK with JTA the jdbc connection is >> created "lazily" with Hibernate. In details if >> "hibernate.current_session_context_class" is "thread" (which is by >> default) then new JDBC connection is always opened when calling >> "hibernateSession.getTransaction().begin()" . But when >> "hibernate.current_session_context_class" is "jta" it retrieves JDBC >> connection lazily when DB call is needed by Hibernate. >> >> At least, last time I used this, it behaved this way. I used plain >> hibernate API though (not JPA EntityManager), but I don't think that the >> behaviour is different with JPA. >> >> With respect to the fact that we have caching layer, there may be many >> HTTP requests, which won't need to open JDBC connection, which might be >> nice performance gain IMO. >> > UserTransaction and JTA would make things easier. CDI would make things > easier too. > > My only concern is that we've just narrowed where Keycloak can be > deployed. Currently, its not to much of a leap to install Keycloak, > Hibernate and Resteasy on Tomcat. > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com >