| Summary: | Error when reimporting freshly deleted nodes on JPA connectors | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise SOA Platform 5 | Reporter: | Van Halbert <vhalbert> |
| Component: | EDS | Assignee: | Van Halbert <vhalbert> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 5.1.0.ER5 | CC: | atangrin, rhauch, vhalbert |
| Target Milestone: | --- | ||
| Target Release: | 5.1.0.CR1 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | http://jira.jboss.org/jira/browse/SOA-2737 | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-02-04 20:39:01 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: | |
|
Description
Van Halbert
2011-01-04 17:33:45 UTC
Link: Added: This issue Cloned from MODE-1066 Security: Added: Public Approved as blocker for 5.1.0 Link: Added: This issue related MODE-1071 After working with the community member that reported this problem, I had an idea as to what the problem was. I proposed MODE-1071 as a potential fix, and after implementing that fix, the community member was able to apply the patch and verify that it solved the problem for MODE-1066. The fix was applied to trunk (see MODE-1071 for details) and will be in the 2.4 release. I am currently trying this patch on our 2.2.x branch (which is used for SOA-P 5.1) to see if this will work correctly. The reported problem is a concern for any JPA source when clients create and remove large amounts of repository content at once (e.g., in one session). The problem is that, especially on MySQL (due to the original problem reported as MODE-691), deleting the unused content took some time and blocked other operations (depending upon transaction isolation), resulting in timeout errors (e.g., the H2 error reported in MODE-1066). When MySQL was configured with default transaction isolation level, other operations could read records that were in the process of being deleted (by the long-running delete operation), and if the delete operation committed before those other operations committed, then a constraint violation could occur. The patch does two things to correct this: 1) It changes how the deletes are made. The way the schema works is that the "large values" are keyed by their SHA-1 and reused in all nodes that have properties with the exact same value. As nodes are removed, some large values are orphaned but remain available to be reused if needed. Previous to this fix, these orphaned large values were deleted as part of the normal operations to add and remove nodes. This was unnecessary, as the only harm in keeping orphaned large values is an ever-increasing DB size. This patch adds a "garbage collection" facility to the connector API (in a backward-compatible way, requiring no changes in any of the connectors), and the JPA source was changed to do support this manual garbage collection. No, the GC-ing is done periodically (by default every 10 minutes) in a background process. 2) The workaround for deleting the large values in MySQL (again, see MODE-691) was also improved dramatically. The result is that this operation is now atomic and done with a single DELETE statement, dramatically improving the performance and reducing the chances of a collision. Changing the transaction isolation level to READ_COMMITTED would mean that there never will be a collision. I will continue to evaluate the patch against the 2.2.x branch, and report back. |