It's not can by default because most people don't need it and xa needs to
have different config. An xa transaction can have a single non-xa resource
joining it though.
On 12 Feb 2018 6:17 pm, "Marek Posolda" <mposolda(a)redhat.com> wrote:
I think you can change existing KeycloakDS to be
"xa-datasource" . Maybe
some configuration properties will need to be changed.
I am not 100% sure why the KeycloakDS is not "xa-datasource" by default.
Maybe just because some databases (H2 ?) have issues with it.
On 12/02/18 13:25, Niels Bertram wrote:
> Yes the 2nd datasource is an XA capable one. Is there any reason why
> we cannot also supply a XA datasource to Keycloak? We have a potential
> 3rd participant in the global transaction (JCA adapter) but need to
> make it last resource. As long as the JCA adapter is consumed (and
> lifecycle managed) within a Keycloak provider that should all work, no? N
> On Mon, Feb 12, 2018 at 6:22 PM, Marek Posolda <mposolda(a)redhat.com
> <mailto:email@example.com>> wrote:
> I recall that if your application is using different datasource
> then "KeycloakDS" (which probably is the case if you are using
> different database then Keycloak), then you need to configure
> second datasource as "xa-datasource" .
> I think it looks right from quickly looking at it.
> On 10/02/18 13:38, Niels Bertram wrote:
>> Hi Marek,
>> using an application managed EntityManagerFactory appear to be
>> working. I created a UserStorageProviderFactory that is managing
>> a entity manager factory and when I use the entity manager in the
>> UserStorageProvider the transaction is managed by the container
>> transaction manager that also manages the Keycloak transactions.
>> Why am I certain about that? Had a few errors in the beginning
>> about 2 datasources trying to enroll as last resort.
>> The main ingredients in this gist.
>> The trick is to tell hibernate
>> where to get the JTA platform transaction manager from.
>> Does that look about right? I have a feeling it could be
>> simplified with some CDI magic ...
>> Cheers Niels
>> On Sat, Feb 10, 2018 at 12:26 AM, Niels Bertram
>> <nielsbne(a)gmail.com <mailto:firstname.lastname@example.org>> wrote:
>> Yes studied that one before asking the question, its close
>> but not close enough. I think I will get away with creating
>> an application managed persistence context with container
>> managed transaction. Then in the provider factory I will read
>> the DataSource name from config and create the entity
>> transaction manager. Am just not too sure if it'll work with
>> the things you do in Keycloak to access these provider EJBs.
>> I kinda need 1 stateful session bean for each provider
>> instance added to the realm and that needs its on
>> EntityManagerFactory which enrolls the entity manager in the
>> JTA from Keycloak. Will report back if I can get something
>> working. Thanks Niels
>> On Sat, Feb 10, 2018 at 12:18 AM, Marek Posolda
>> <mposolda(a)redhat.com <mailto:email@example.com>> wrote:
>> I suggest to look at this example:
>> AFAIK It's probably closest thing to your usecase, which
>> we have.
>> Dne 8.2.2018 v 17:49 Niels Bertram napsal(a):
>> Hi there,
>> we have a requirement to set the jndi datasource name
>> on a UserFederation
>> provider when added to a realm to support connecting
>> different realms in
>> the same Keycloak server to different databases. Been
>> through the examples
>> and read a few emails from around 2016 in the
>> developer list but do not
>> find anyone who'd actually done this before. we could
>> create a user managed
>> EntityManagerFactory within the federation provider
>> factory but the
>> question is then how can we inject it into the
>> container context and enlist
>> our transactions in the JTA?
>> Has anyone ever had to implement something like that?
>> keycloak-user mailing list
keycloak-user mailing list