[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5053?page=c...
]
Rostic Sheykhet updated HHH-5053:
---------------------------------
Attachment: Hibernate351BugTest.java
I have also experienced this issue with the SequenceHiLoGenerator in Hibernate 3.5.1 with
Oracle 10g sequences -- I believe that the code is broken in
org.hibernate.id.SequenceHiLoGenerator.generate() method -- the "lo" does not
seem to ever be incremented, and thus the database sequence is only updated once, on
startup. The problem manifests if you have several instances of the server running
against the same DB, or when you restart the server. I am attaching my test case for H2.
Duplicate primary keys when using the SEQUENCE strategy due to
underlying sequence not being updated when the SequenceGenerator's allocatedSize is
greater than 1
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-5053
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5053
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.0-CR-2
Environment: Hibernate 3.5.0-CR-2
PostgreSQL 8.4.1 (JDBC driver 8.4-701 JDBC4)
Glassfish v3 (build 74.2)
JDK 1.6.0_18
Reporter: atomicknight
Attachments: Hibernate351BugTest.java, jpa-test.war, table1.sql
When the SequenceGenerator's allocatedSize is greater than 1, the underlying sequence
associated with the table doesn't ever seem to be updated by Hibernate except on
application startup. The test case uses an allocatedSize of 3, corresponding to an
increment value of 3 in the underlying sequence.
Here's how to use the test case (requires EJB 3.1):
1) Set up the database using the attached SQL dump, then load the application
2) Access the test page via
http://localhost:8080/jpa-test/test. You should see a page
with the word "Done!"
3) Undeploy and redeploy the application
4) Access the test page again. You should encounter an error page indicating that the
transaction was aborted.
Here's what I observed at the database level while following the above steps:
1) Sequence is created with a start value of 1 and increment value of 3.
2) Hibernate increments the sequence to 4. The application then inserts rows with IDs
12-31.
3) No change - the sequence still has a value of 4.
4) Hibernate increments the sequence to 7. The application attempts to insert a row with
ID 21, but fails because the ID was already used in step 2.
Setting the SequenceGenerator's allocatedSize to 1 as well as changing the increment
value of the sequence to 1 gives the correct behavior.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira