Help Desk Ticket Reference: https://na7.salesforce.com/500A0000006knT1 project_key: JBEPP Testing has revealed that using a managed tx datasource and JTA for IDM results in fewer database connections needed for IDM. But currently this configuration does not work properly for JCR, see EXOJCR-480. Once EPP includes a newer JCR version with JTA support, this configuration should be re-evaluated.
Link: Added: This issue depends EXOJCR-480
Link: Added: This issue is related to JBQA-4436
Release Notes Docs Status: Added: Not Yet Documented
Labels: Added: EPP_5_2_1_Candidate
Labels: Removed: EPP_5_2_1_Candidate
Wiki link: https://community.jboss.org/wiki/JTAIntegrationWithGateIn
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: CAUSE: EPP didn't support JTA in previous releases. There are some problems related to it, especially the fact that without JTA support, there is need to obtain DB connection for IDM database for each HTTP request of logged user. In some environments, this may cause problems related to lack of DB connections and worse performance. FIX: It's possible to configure EPP for JTA support, which can be useful especially for reduce number of DB connections opened against IDM database. JTA is not enabled by default, so customer need to do couple of steps to enable it. These steps are described in wiki page https://community.jboss.org/wiki/JTAIntegrationWithGateIn NOTE: Described steps on wiki page are related to GateIn. In EPP some steps are slightly different.Especially: - In EPP there are different names of datasources "gatein-idm" and "gatein-jcr" instead of the names "jdbcidm" and "jdbcjcr", which are used in GateIn and are used on wiki page. - Step 2 (JCR configuration of DataSourceProvider) is not needed because it's enabled by default in EPP.
There still seems to be some problems with JTA in org.management & performance. One issue reported: https://bugzilla.redhat.com/show_bug.cgi?id=840917 One more problem: - when I run performance test in anonymous mode (with local or xa jta datasources), there is no issue and idm connections works as expected (only 1 idm connection is used during whole test) - when I run performance test for logged users (with xa jta datasource), around 1200 users exceptions appears at log: javax.transaction.RollbackException: [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] Could not commit transaction. ... Caused by: org.jboss.cache.optimistic.DataVersioningException: Transaction attempted to create /org/hibernate/cache/StandardQueryCache/QUERY/sql: select this_.ID as ID4_1_, this_.IDENTITY_TYPE as IDENTITY2_4_1_, this_.NAME as NAME4_1_, this_.REALM as REALM4_1_, hibernatei2_.ID as ID11_0_, hibernatei2_.NAME as NAME11_0_ from jbid_io this_ inner join jbid_io_type hibernatei2_ on this_.IDENTITY_TYPE=hibernatei2_.ID where this_.NAME=? and this_.IDENTITY_TYPE=? and this_.REALM=?; parameters: users, 3, 2, ; transformer: org.hibernate.transform.CacheableResultTransformer@13a525 anew. It has already been created since this transaction started, by another (possibly remote) transaction. We have a concurrent creation event. I run it twice and same behavior was shown. You can also see the progress of jmx statistics: users idm_AvgConnectionsInUse idm_MaxConnectionsInUse 0 0 1 20 0 1 200 0 1 400 0 1 600 0 2 800 0 2 1000 0 4 1200 4 25 1400 1 50 1600 3 50 1800 3 50 2000 4 50 Assigning for 5.2.2 CR01
From the log, it seems that DataVersioningException occurs only during bigger load (1200 users and more) and seems to be caused by using optimistic locking for Hibernate query cache. I think it can be be fixed by using different locking scheme (like mvcc) but it will require further investigation and probably changing locking scheme is not acceptable for 5.2.2 release... Some possibly related links for later investigation: https://community.jboss.org/thread/157221 https://issues.jboss.org/browse/SOA-3084
I don't think we'll be able to investigate more next week and it'll need to wait for Marek to return from PTO. I'm scheduling for CR01 but it may need to be further postponed.
This issue is introduced by fix of https://bugzilla.redhat.com/show_bug.cgi?id=834635. So workaround for this issue is to comment the configuration of TransactionManagerLookup in JBoss cache configuration file gatein.ear/02portal.war/WEB-INF/conf/organization/picketlink-idm/jboss-cache.xml: <!--<transaction transactionManagerLookupClass="org.jboss.cache.transaction.JBossStandaloneJTAManagerLookup" />--> This is only a workaround, so I won't fix it into EPP_5.2 branch as it can also potentially introduce other regressions in EPP 5.2.2. The cause is that IDMUserListAccess added into IntegrationCache is sometimes lost after commit of JTA transaction and old instance of IDMUserListAccess is restored. Proper fix will require further investigation at JBoss Cache level. Simple application for test this issue: https://github.com/mposolda/jcr-transaction-test
JTA support was polished and improved. If there are any additional issues with it they should be filled as a new BZ