Let me clear this up, the current JTA transction is suspended if and only if KeycloakTransactionManager.begin() is invoked. All our current usages of KeycloakTransactionManager assume that a brand new "transaction" is started when used. Eventually we can add a new method that assumes the Keycloak Session is being used with a JTA transaction. In this case, KeycloakTransactionManager would be registered with an existing JTA transaction.
On 8 August 2016 at 23:51, Bill Burke <bburke@redhat.com> wrote:
Ok,
New provider deployer exists in master. You can package components in
any type of deployment. i.e. within a EAR or WAR. Hot deploy works as
well. The deployers/ directory and deployment-scanner subsystem is now
back in the server. Also added JTA transactions. So, now when a
KeycloakSession is created a new JTA transaction is associated with the
KeycloakTransactionManager. If there was an existing JTA transactionn,
that transaction is suspended and resumed after the keycloak session
completes. JTA TransactionManager lookup has an SPI now which you can
enable/disable in keycloaks-server.json. If no transaciton manager
exists i.e. within the testsuite, JTA is not used at all.
Why is the existing transaction suspended? Should it not just join the existing transaction?