Java EE (Java Enterprise Edition) General Discussion

I have a general Question about the mapping of the SQL datatype BIGINT. I discovered, that there are some different behaviour depending on the JPA implementation. I tested with TopLink Essentials (working) and with Hibernate (not working).

Here is the case:

Table definition:

/*==============================================================*/
/* Table: CmdQueueIn */
/*==============================================================*/
create table MTRACKER.CmdQueueIn
(
CmdQueueInId bigint not null global autoincrement,
Type int,
Cmd varchar(2048),
CmdState int,
MLUser bigint not null,
ExecutionTime timestamp,
FinishTime timestamp,
ExecutionServer varchar(64),
ScheduleString varchar(64),
RetryCount int,
ResultMessage varchar(256),
RecordState int not null default 1,
CDate timestamp not null default current timestamp,
MDate timestamp not null default current timestamp,
constraint PK_CMDQUEUEIN primary key (CmdQueueInId)
);

The java class for this table has the following annotation for the primary key field:

.......
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
@Column(name = "CmdQueueInId", nullable = false)
private BigInteger cmdQueueInId;
.....

When using hibernate 3.2.1 as JPA provider I get the following exception:

avax.persistence.PersistenceException: org.hibernate.id.IdentifierGenerationException: this id generator generates long, integer, short or string
at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:629)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:218)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:176)
at $Proxy16.persist(Unknown Source)
at com.trixpert.dao.CmdQueueInDAO.save(CmdQueueInDAO.java:46)
at com.trixpert.test.dao.CmdQueueInDAOTest.testCreateNewCmd(CmdQueueInDAOTest.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at
......
Caused by: org.hibernate.id.IdentifierGenerationException: this id generator generates long, integer, short or string
at org.hibernate.id.IdentifierGeneratorFactory.get(IdentifierGeneratorFactory.java:59)
at org.hibernate.id.IdentifierGeneratorFactory.getGeneratedIdentity(IdentifierGeneratorFactory.java:35)
at org.hibernate.id.IdentityGenerator$BasicDelegate.getResult(IdentityGenerator.java:157)
at org.hibernate.id.insert.AbstractSelectingDelegate.performInsert(AbstractSelectingDelegate.java:57)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2108)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2588)
at org.hibernate.action.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:48)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:290)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:180)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:108)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:131)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:87)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:38)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:618)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:592)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:596)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:212)
... 34 more

This means, that their ID generator does not support java.math.BigInteger as datatype.

But the code works if I take TopLink essentials as JPA Provider.

Looking at the spec shows the following:

In chapter 2.1.4 "If generated primary keys are used, only integral types will be portable." Integral datatypes are byte, short, int, long and char. This would mean, that the Hibernate implementation fits the spec but there seem to be a problem in general with BIGINT datatypes.

I use a SYBASE database. There it is possible to declare a UNSIGNED BIGINT. The range of numbers is therefore 0 - 2^64 - 1. Since in Java a long is always signed it would mean its range is from -2^63 -1 to 2^63 -1. So a mapping of BIGINT to java.lang.long could result in an overflow.

The interesting thing is, that I used NetBeans to reverse engineer an existing database schema. It generated for all Primary Keys of Type BIGINT automatically a java.math.BigInteger. But for other fields (not being keys) it mapped BIGINTs to java.lang.long.

It looks like there are some problems with either the spec itself or the implementation of it. While TopLink seems to handle the problem correctly, Hibernate doesn't. But Hibernate seems to fulfill the spec.

Is anybody familiar with the Spec reading this and can elaborate a little about this situation?

Many thanks for your input and feedback.

Tom