"... no longer relevant..."

This is no longer relative in current code and 3.2 branch is not maintained

This occurs in 3.2.7

This is one of those insidious bugs, as it does not blow up at runtime, but instead returns the wrong value. We were burned by this in our production environment. The code fix offered by the reporter here is spot on! The number being loaded into hival from doWorkInNewTransaction() should be a long. And the following multiplication should be cast for clarity as shown in the attached version.

Offending code:

org.hibernate.id.MultipleHiLoPerTableGenerator

hi = hival * (maxLo+1);

where hival and maxLo are both ints. The result, hi, is a long. But that doesn't matter to java when it does the computation. It computes the result as an int, overflows the max lengh, then casts the result to along. To fix, one just needs to cast the result explicitely, or change hival to be a long (see bug reporter's code).

Here's the JUnit test I wrote to prove this.

@Test public void testIntToLong()
{
int hival = 34550207;
int maxLo = 5000;

long uncastHi = hival * (maxLo + 1);
long expectedHi = (long) hival * (maxLo + 1);

assertEquals("Wishing these two results matched!", expectedHi, uncastHi);
}

Yields: junit.framework.AssertionFailedError: Wishing these two results matched! expected:<172785585207> but was:<986893367>

The test fails, demonstrating the bug in the generate() method. Interestingly, this problem was not duplicated in the TableHiLoGenerator in the same package, in that it sets the return value of the super.generate() as a long.

long val = ( (Number) super.generate(session, obj) ).longValue();

But it does suffer from treating that returned hival from the database as an Integer, which will suffer the same truncation problems once your hival grows beyond the max size of a java int. Perhaps this should be handled as a seperate bug.

Because database numeric representation (that might be used for primary keys) is not limited to 32/64bits representation, why not upgrade this class to be as compliant (to big numbers) as possible by using BigInteger representation.

Actually I've encountered the problem of overflow using this class!!!!
Stack Trace sample:
HibernateJdbcException: JDBC exception on Hibernate data access; nested exception is org.hibernate.exception.GenericJDBCException: could not get or update next value...
Caused by
java.sql.SQLException: JZ00B: Overflow numérique... (Localisation looks strange here)
(Caused by ResultSet.getInt() on a too large value stored in the database)

After one year no one seamed to take into account the consequences on users.
In my point of view this bug is Fatal :

• Database integrity is endangered or (at least)

• Application could not operate on concerned tables (our case)!

For so "trivial" changes fixing a big threat on users I hope there will be a fix soon!

Please vote!!!