Bug 973039
| Summary: | Inconsistent exception handling in IDM DAO layer | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Portal Platform 6 | Reporter: | Martin Weiler <mweiler> |
| Component: | Portal | Assignee: | Nobody <nobody> |
| Status: | CLOSED UPSTREAM | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.0.0 | CC: | epp-bugs, mposolda, tkyjovsk |
| Target Milestone: | ER02 | ||
| Target Release: | 6.1.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Cause: In releases prior to JPP 6.1 some exceptions thrown from IDM were not correctly handled in JPP. Especially we sometimes did not perform rollback of Hibernate transaction in case of Hibernate error, which could lead to inconsistent state and incorrect behaviour.
Fix: Currently all fixes thrown by IDM layer are correctly handled and logged and we are always perform rollback of DB transaction in both non-JTA and JTA configuration
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2025-02-10 03:27:55 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Verified in 6.1.0.ER02. This product has been discontinued or is no longer tracked in Red Hat Bugzilla. |
Description of problem: Exception handling in the IDM DAO layer is inconsistent/incomplete: * GTNPORTAL-2928: Exceptions are swallowed completely * GTNPORTAL-3110: Exception handling is inconsistent How reproducible: Always Steps to Reproduce: 1. IDM operation fails with an error (eg. Hibernate exception, database exception) in, for example, UserDAOImpl.authenticate(..) method when the lastLoginTime attribute is saved for the user 2. An exception is thrown: ERROR [org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl] ORA-00001: unique constraint (PORTAL_IDM_OWNER.JBID_IO_ATTR_TEXT_VALUES_PK) violated : org.hibernate.exception.ConstraintViolationException: ORA-00001: unique constraint (PORTAL_IDM_OWNER.JBID_IO_ATTR_TEXT_VALUES_PK) violated ... at org.exoplatform.services.organization.auth.OrganizationAuthenticatorImpl.validateUser(OrganizationAuthenticatorImpl.java:152) [exo.core.component.organization.api-2.5.1-CP01-redhat-1.jar:2.5.1-CP01-redhat-1] Caused by: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (PORTAL_IDM_OWNER.JBID_IO_ATTR_TEXT_VALUES_PK) violated 3. Every IDM operation that happens afterwards on the same thread is failing: INFO [org.exoplatform.services.organization.idm.UserDAOImpl] Cannot obtain user: user1; : org.picketlink.idm.common.exception.IdentityException: Cannot obtain Hibernate Session ... Caused by: org.hibernate.TransactionException: nested transactions not supported at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin(AbstractTransactionImpl.java:152) [hibernate-core-4.1.6.Final-redhat-3.jar:4.1.6.Final-redhat-3] at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreSessionImpl.startHibernateTransaction(HibernateIdentityStoreSessionImpl.java:207) [picketlink-idm-hibernate-1.4.1.Final-redhat-1.jar:1.4.1.Final-redhat-1] at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreSessionImpl.startHibernateTransactionIfNotStartedYet(HibernateIdentityStoreSessionImpl.java:195) [picketlink-idm-hibernate-1.4.1.Final-redhat-1.jar:1.4.1.Final-redhat-1] at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateSession(HibernateIdentityStoreImpl.java:2786) [picketlink-idm-hibernate-1.4.1.Final-redhat-1.jar:1.4.1.Final-redhat-1] Actual results: Exception is not handled correctly, causing the transaction status captured in HibernateIdentityStoreSessionImpl.hibernateTxStatus ThreadLocal to be wrong, which affects all subsequent operations on the same thread. Expected results: Exception is handled correctly, not affecting further IDM operations on the same thread. Additional info: