[keycloak-dev] Hybrid store committed

Marek Posolda mposolda at redhat.com
Tue Jul 8 10:46:50 EDT 2014


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.

Marek
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at 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 at redhat.com>
>>>> To: keycloak-dev at 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
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



More information about the keycloak-dev mailing list