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.
Marek
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:mposolda@redhat.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.
Marek
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.
>
>
https://gist.github.com/bertramn/cbc4eec5e7b13e28099f4165a0c15b29
> <
https://gist.github.com/bertramn/cbc4eec5e7b13e28099f4165a0c15b29>
>
>
> The trick is to tell hibernate
>
<
https://gist.github.com/bertramn/cbc4eec5e7b13e28099f4165a0c15b29#file-cu...
> 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:nielsbne@gmail.com>> 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:mposolda@redhat.com>> wrote:
>
> I suggest to look at this example:
>
https://github.com/keycloak/keycloak/tree/master/examples/providers/user-...
>
<
https://github.com/keycloak/keycloak/tree/master/examples/providers/user-...
>
> AFAIK It's probably closest thing to your usecase, which
> we have.
>
> Marek
>
> 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?
>
> Cheers,
> NIels
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
> <
https://lists.jboss.org/mailman/listinfo/keycloak-user>
>
>
>
>
>