Hibernate version:
00:58:14,420 INFO [Version:redirect.system.config] Hibernate EntityManager 3.2.0.GA
00:58:14,446 INFO [Version:redirect.system.config] Hibernate Annotations 3.2.0.GA
00:58:14,457 INFO [Environment:redirect.system.config] Hibernate 3.2.1

Mapping documents:

public class User implements Serializable, Comparable
{
@TableGenerator(name="user_gen",
table="id_generator",
pkColumnName="table_name",
valueColumnName="id_block",
pkColumnValue="user",
allocationSize = 1)
@Id @GeneratedValue(strategy=GenerationType.TABLE, generator="user_gen")
@Column(name = "user_id", nullable = false)
private Integer userId;


Code between sessionFactory.openSession() and session.close():

na

Full stack trace of any exception that occurs:

na

Name and version of the database you are using:

MySQL 5

The generated SQL (show_sql=true):

na

Debug level Hibernate log excerpt:

na


Hi guys. I'm fairly new to using hibernate with EJB3 so please have mercy - I'm hoping somebody can point me in the right direction regarding docs, etc. I was using toplink as my JPA provider until recently, and things were working fine (in this regard anyhow!).

I'm using table generation for my keys throughout the app. We've had the app deployed in a staging environment without problems, using an allocation size of 50 as an optimization.

Sadly I've misplaced the copy of the log output, and I can't reproduce it in our staging environment. But basically, our ID went nuts - super high. We were at about 280,000 and incrementing by 50 as it should (like toplink), but then in production suddenly, it was as though it MULTIPLIED by 50, and our ID's were in the 14,000,000 range. What the heck? Is this "expected" behaviour?

The logs indicated no error, but the log message came from MultipleHiLoPerTableGenerator (referenced it anyhow), and I *believe* it logged that the "low" value (i think it was the low value) was what I expected at about 284,000, but then BAM it said it generated the 14,000,000 value.

I changed allocation size to 1, and it's fine now, but slower of course.

Thanks,

Mal.

The spec is fairly vague regarding this issue.
The Hibernate algorithm is basically hi*allocSize + lo
where hi is the value in DB, lo is an in memory counter

You can always implement the same behavior as TL using a @GenericGenerator

Emmanuel,

Thanks for the reply. but I'm a little confused about what the hi and lo values represent.

I've beek trying to find some documentation what the hi, and lo, values represent in a hilo generator of the kind Hibernate is using. I looked in the hibernate docs, and all I'm getting is :

"uses a hi/lo algorithm to efficiently generate identifiers of type long, short or int, given a table and column (by default hibernate_unique_key and next_hi respectively) as a source of hi values. The hi/lo algorithm generates identifiers that are unique only for a particular database."

This implies that the hi values are coming from my id table, which is what I would expect. But what is the lo values?

Thanks,

Mal.

p.s. why would it perform that multiplication anyhow?

There is not much I can say than the actual formula

next_id = hi * Allocation_Size + lo
if lo >= Allocation_Size {
read the next hi from the DB and update the DB with hi+1
set lo to 0
}

Thanks Emmanuel, that makes a lot of sense now. Although I don't like the multiplication :-( I'll have to write my own. Its a shame to have to use hibernate specific mechanisms to do so however in the interest of portability.

Mal.

This is something the next spec will have to address.