[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3608) DB sequence numbers are not unique when using the pooled SequenceStyleGenerator in multiple JVMs with the same DB

[Steve Ebersole (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=37047#action_37047 ] 

Steve Ebersole commented on HHH-3608:
-------------------------------------

So much to cover...

Why the 2 selects?  Because Hibernate uses the sequence to "reserve" its block of id values.  For the sake of simplicity lets say you have "start with 1 increment by 10".  When you first obtain the next value from the table its value is 1.  However, the values you really want Hibernate to generate are 1-11.  The second select bumps the "current value" in the sequence to 11.  So its not just about calculating the upper limit for Hibernate's use in memory.  This is by far the safer approach and as it is in use in existing applications will not be getting changed.  As noted, if you do not like this behavior it is easy enough to plugin in your own optimizer or generator.

Unfortunately there is no way that I know of to "synchronize" on a sequence.  You can't acquire pessimistic locks on it which would be the safest and is actually the only way to have it work in both the "other jvm" and "external app" use cases.  So, given that the 2 callback.getNextValue() calls will remain in place, what is it you suggest?

> DB sequence numbers are not unique when using the pooled SequenceStyleGenerator in multiple JVMs with the same DB
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: HHH-3608
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3608
>             Project: Hibernate Core
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.2.6, 3.3.0.GA, 3.3.0.SP1, 3.3.1
>         Environment: Hibernate 3.2.6, Oracle (any version)
>            Reporter: Matthias Gommeringer
>            Priority: Blocker
>         Attachments: CustomPooledOptimizer.java, PooledOptimizerTest.java
>
>
> We have several Application Servers (=JVMs) running each of them using Hibernate-Objects with the SequenceStyleGenerator+pooled configured. In unpredictable time intervals it happens that hibernate assigns the same ID to two completely different objects which results in a UniqueConstraintViolation exception from the database. Here an example with a description where hibernate fails:
> DB-Sequence setup:
> start=0
> increment=2
> PooledOptimizer.generate() with 2 threads (first assignment of hiValue/value):
> JVM-1                                                 JVM-2
> value=0=callback.nextval
>                                                             value=2=callback.nextval
> hiValue=4=callback.nextval
>                                                             hiValue=6=callback.nextval
> The problem's cause is in the PooledOptimizer.generate: when it initializes
> the value+hiValue for the first time it invokes callback.nextValue() twice which 
> may provide values that do not belong to each other. The reason is that 
> between the assignment of "value" and "hiValue" another JVM can retrieve a
> DB sequence value from the callback which leads to an inconsistent "value" and "hiValue"
> relation (see example above).
> A fix that works for multiple JVMs would be to invoke the "callback.getNextValue()" maximum once
> per "optimizer.generate()" call:
>     public synchronized Serializable generate(AccessCallback callback) {
>         if ( hiValue < 0 ) {
>             value = callback.getNextValue();
>             hiValue = value + incrementSize;
>         }
>         else if ( value >= hiValue ) {
>             value = callback.getNextValue();
>             hiValue = value + incrementSize;
>         }
>         return make(value++);
>     }
> I attached a testcase that prooves the described problem (you can see that the IDs "2" and "3" are assigned two times).
> I would be very thankful if this problem could be fixed very soon since it is a showstopper which
> occurs very unpredictably.

-- 
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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira