Bugzilla – Full Text Bug Listing
| Summary: | Eclipselink choosing the wrong table id generator | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Brett Bergquist <bbergquist> |
| Component: | Eclipselink | Assignee: | Nobody - feel free to take it <nobody> |
| Status: | REOPENED --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | eclipselink.orm-inbox, gordon.yorke, jamesssss, tom.ware |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
The issue here is you are specifying the optional pkColumnValue to be identical for all of the generators. This particular attribute should be considered advanced configuration and is used to specify the row in the table that will be used for this Generator (see 11.1.46 of the JPA specification) By giving all of the generators the same pkColmnValue you are instructing the Persistence Provider to use the same row for all of the Sequence Generators and therefore they will share this sequence. You can leave the pkColumnValue undefined and the Persistence Provider will assign it's own value that will keep the generators separate or specify a unique value. Correct, I am specifying a row in the generators but these generators are in different schemas, different tables, and are differently identified generators. Your comment "used to specify the row in the table that will be used for 'this' Generator" indicates that the Generator is what must be unique and in fact if you have duplicate Generator names, deployment will fail. There is nothing in the spec that says the "pk-column-value" must be unique across generators that I can find, only that the generator names must be unique. My interpretation of the spec is that the "generator-name" identifies the generator to use and the attributes specified for that "generator" are the ones that the persistence provider should use. I think this is still a bug and would like to have it reopened. I missed the different schema names in the original posting. At first glance the generators appeared identical to me except for the name which although would have specified unique generators would have practically meant that the same sequence values be shared amoung the generators. With the different schema names EclipseLink should be accessing different tables. This is a bug in EclipseLink. The issue is that our TableSequence uses the sequenceName as the sequence table sequence column value. JPA however has a distinct setting for the sequenceName and the sequence column value. Currently we ignore the sequenceName and just use the sequence column value. This should be fixed so we have a name and a columnValue in TableSequence so the name is the proper JPA name, and the value is independent. Setting target and priority. See the following page for details of the meanings of these fields: http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink |
Build Identifier: Eclipselink 1.1.3 I am running eclipselink 1.1.3 and have custom table id generators. From my "orm.xml": <entity class="com.canoga.nms.pkg.pkg9145.v1.device.entity.DeviceSummary9145"> <table-generator schema="PKG_9145_V1" table="ID_GENERATOR" pk-column-name="SEQ_NAME" value-column-name="SEQ_COUNT" name="DEVICESUMMARY_ID_GENERATOR_PKG_9145_V1" pk-column-value="DEVICESUMMARY_ID"/> <attributes> <id name="id"> <generated-value strategy="TABLE" generator="DEVICESUMMARY_ID_GENERATOR_PKG_9145_V1"/> </id> </attributes> </entity> <entity class="com.canoga.nms.pkg.pkg9161.device.entity.DeviceSummary9161"> <table-generator schema="PKG_9161" table="ID_GENERATOR" pk-column-name="SEQ_NAME" value-column-name="SEQ_COUNT" name="DEVICESUMMARY_ID_GENERATOR_PKG_9161" pk-column-value="DEVICESUMMARY_ID"/> <attributes> <id name="id"> <generated-value strategy="TABLE" generator="DEVICESUMMARY_ID_GENERATOR_PKG_9161"/> </id> </attributes> </entity> <entity class="com.canoga.nms.pkg.pkg9145e10g.device.entity.DeviceSummary9145E10G"> <table-generator schema="PKG_9145E10G" table="ID_GENERATOR" pk-column-name="SEQ_NAME" value-column-name="SEQ_COUNT" name="DEVICESUMMARY_ID_GENERATOR_PKG_9145E10G" pk-column-value="DEVICESUMMARY_ID"/> <attributes> <id name="id"> <generated-value strategy="TABLE" generator="DEVICESUMMARY_ID_GENERATOR_PKG_9145E10G"/> </id> </attributes> </entity> What I am seeing is that Eclipselink is choosing the wrong generator for the "com.canoga.nms.pkg.pkg9145.v1.device.entity.DeviceSummary9145" entity. It is using the generator specified for the "com.canoga.nms.pkg.pkg9145e10g.device.entity.DeviceSummary9145E10G" entity. Note that all use the same "pk-column-value" with the same constant "DEVICESUMMARY_ID". In the log I see displayed: [#|2010-05-19T10:58:45.187-0400|FINEST|sun-appserver2.1|org.eclipse.persistence.session.file:/C:/package/glassfish/domains/domain1/applications/j2ee-apps/csem/csem-core-api.jar-csem-PU.sequencing|_ThreadID=13;_ThreadName=pool-1-thread-3;ClassName=null;MethodName=null;_RequestID=bd27fedc-98e1-4bf4-a1ad-bc7dc26a0136;|sequence DEVICESUMMARY_ID: preallocation size 50|#] Note that I only see this once, not for each entity. So on a whim, I decided to change the "pk-column-value" to be unique for each entity. Now it chooses the correct one. But I would assume that the table identity information would be chosen based upport the "generator" value assigned to each id attribute and then from the generator use the correct schema, table, and row. This is not happening. James.Sutherland@oracle.com replied: Yes, this is a bug in how EclipseLink defines table sequencing. Please log a bug for this issue. Your workaround to use unique pk-column-value's is correct. Reproducible: Always Steps to Reproduce: 1. Create multiple entities each using a table id generator that is specified in the orm.xml 2. For each id generator specification use a separate schema, table, and generator name, but use the same "pk-column-value" 3. Persist JPA entities using the first entity and notice that the wrong table id generator is used to acquire the next ID.