[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3608?page=c...
]
Steve Ebersole commented on HHH-3608:
-------------------------------------
Ryan, I have developed database applications for nearly 10 years. I understand sequences.
So please dont use rude comments such as this. There is no "fundamentally
broken" here except for you missing the point that "By getting 1 and knowing
that the increment is 10, you have already reserved 1-10 for yourself." is merely
*an* interpretation of what that one means. As long as you and everyone else using that
sequence agree and understanding that assumption everything is good. Now what happens
when your application reads first value (1) and assumes it has reserved 1-10, but another
application reads the next value (11) and assumes it has reserved 1-10? The assumption
here is whether the database is storing the upper value or the lower. Just because *you*
think it should be interpreted as lower does not make it a universal truth.
Bryan, that might work though it would come down to how (if) the calls got interleaved.
I'll have to think on that some more. As to your question about why I think its
safer, see my point above to Ryan about different assumptions as to the sequence value.
Matthias that is completely not true on any databases supporting sequences I know of.
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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira