[keycloak-dev] Hybrid store committed

[Marek Posolda]

Yeah, I wonder if this can be an optional feature? You will have 
possibility to choose either JTA or delegate to EntityManager 
transaction API. So something like:

public void begin() {
  if (configuration.isJTAEnabled()) {
    // delegate to UserTransaction
  } else {
   // delegate to EntityManager
  }
}

With Tomcat, embedded Undertow or trimmed Wildfly, people will always 
need to use EntityManager (JPA API). But on AS7/Wildfly they may use JTA.

Marek

On 8.7.2014 17:19, Stian Thorgersen wrote:
> 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 at redhat.com>
>> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at 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
>>