Bugzilla – Full Text Bug Listing
| Summary: | Intermittent multiple assignments to same column | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Joseph Chiu <joseph> | ||||
| Component: | Eclipselink | Assignee: | Vikram Bhatia <vikram.jeet.bhatia> | ||||
| Status: | CLOSED INVALID | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P2 | CC: | eclipse, julo, tom.ware, vikram.jeet.bhatia | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 181351 [details]
TAR-GZ of Source file and README.txt which shows the error
Since it's intermittent, this is a rather concerning issue. I'm worried that production code is failing and a developer could have inadvertently ate the exception or we missed it in monitoring. You got my vote. Setting target and priority. See the following page for details about these fields: http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines I had previously stated my impression that either the problem occurs always for a program run, or it does not occur at all. I was wrong about that: In one example, I had the program run over a small batch of work, and within the same "session" (only one EntityManagerFactory, and one EntityManager created from that factory), the error occurred once, amidst four successful updates. (Each update being wrapped by a beginTransaction and commitTransaction.) BTW, this bug continues to exist in 2.1.2v20101206-r8635, not just 2.1.1.v20100817-r8050 Workaround ---------- Clone the embeddable object instead of re-using the fetched embeddable object for different embeddable field in same entity. // KeyPair fooVal = cr.getRV().min(fooLimit).max(KeyPair.BIG_ZERO); KeyPair fooVal2 = cr.getRV().min(fooLimit).max(KeyPair.BIG_ZERO); KeyPair fooVal = new KeyPair(fooVal2.getKey(), fooVal2.getVal()); As per JPA 2.0 Specifications, Section 2.5 2.5 Embeddable Classes Embedded objects belong strictly to their owning entity, and are not sharable across persistent entities. Attempting to share an embedded object across entities has undefined semantics. So, embedded objects cannot be shared. I ran into this problem as well. Originally, I tought that the issue is deterministic. However, trying to find out cases where the issue pops up and when it does not I ran into cases where the issue randomly appears. I ran into this and while repeating the same thing the query generated for entity update is: UPDATE agm.task SET actual_release = ?, planned_release = ?, task_resolution = ? WHERE (entity_id = ?) The query that is generated in case of failure (while doing the same stuff with the same entities) is UPDATE agm.task SET actual_release = ?, actual_release = ?, task_resolution = ? WHERE (entity_id = ?) Looks like the naming of columns does not work well for some cases for embedded entities. I'll try to do more troubleshooting. Hmmm... sometime the duplicate columns are even the other way round... UPDATE agm.task SET planned_release = ?, planned_release = ?, task_resolution = ? WHERE (entity_id = ?) The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink |
Build Identifier: 2.1.1.v20100817-r8050 When persisting changes, sometimes the same column shows up twice in the same UPDATE query: Caused by: Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.1.1.v20100817-r8050): org.eclipse.persistence.exceptions.DatabaseException Internal Exception: org.postgresql.util.PSQLException: ERROR: multiple assignments to same column "cv" Error Code: 0 Call: UPDATE FOORESULT SET CV = ?, CV = ?, LASTUPDATED = ? WHERE ((ID = ?) AND (LASTUPDATED = ?)) bind => [2.93, 2.93, 2010-10-20 17:46:30.722615, 1, 2010-10-20 17:46:29.806275] Query: UpdateObjectQuery(lzk.FooResult@1cef4f7) at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:333) The problem appears intermittently. It seems to be related to the @Embeddedable's. It seems that the problem is tied to each run invocation. Either the failure occurs for all attempts to update; or passes. Reproducible: Sometimes Steps to Reproduce: I will attach a gzip'd tar file witih a stripped down set of soure code that replicates the problem. After installing Postgres 8.4., the steps to reproduce are: $ ./creatuser.sh elissue $ ./createdb.sh elissue $ mvn test $ mvn test $ ... repeat until failure exception is thrown. As shown in the included README.txt, I had to run the test program 4 times to cause the error to appear.