How to get newly assigned Id with EntityManager?

jbchurn · **Posted:** Wed Apr 30, 2008 5:38 am

Hi,

For Hibernate session, i previously use the code as below to get the newly assigned id for an inserted record:

Code:

_session.save(dept);
intId = ((Integer)_session.getIdentifier(dept)).intValue();

What should I use if I'm using EntityManager?

Code:

em.persist(dept);
intId = ... how should I code here ?...

Please advise.

Regards,
Jap.

hardy.ferentschik · **Posted:** Wed Apr 30, 2008 6:07 am

Hi,

The persist() call of the EntityManager does indeed not return an id and I don't think there is a way of doing this using pure JPA. If you really need the id and you don't mind exposing Hibernate classes you can call em.getDelegate() which will return an Object you can cast to a Hibernate Session.

--Hardy

jbchurn · **Posted:** Wed Apr 30, 2008 6:17 am

Hi,

I see, actually I'm trying to keep to JPA whenever possible for the time being.

If after I em.persist(dept);, and then immediately I call "dept.getId()", do you think I'll be able to get the id? I haven't try this, but perhaps you can share your advice.

Thanks.

Regards,
Jap.

hardy.ferentschik · **Posted:** Wed Apr 30, 2008 2:14 pm

Hi,

the entity manager does not have to generate the id directly when you call persist. It will depend on your id generator strategy. If you for example use identity or select the id will only be assigned when the transaction commits or flush() is called. If you use a sequence generator you might be fine with calling getId() directly after the persist(), but I would not bet on it. Do you really need the id right after persist() even before the transaction commits?

--Hardy

jbchurn · **Posted:** Thu May 01, 2008 3:08 am

I need that because I need to pass the id to another method.

Abram · **Joined:** Wed Apr 23, 2008 12:07 pm **Posts:** 22

try not to think about ids. let hibernate do this. dont give the id to another method, but the object. ;)

andydale · **Posted:** Mon May 05, 2008 2:31 am

Hi,

Have you tried to call em.merge(dept) and then call getId() on the returned object ?

Cheers,

Andy

hardy.ferentschik · **Posted:** Mon May 05, 2008 5:39 am

Hi,

provided that you commit the transaction before you call getId() it should be ok. I think the danger is to call getId() directly after persist() within the same transaction. Switching to merge() seems just another crutch.

--Hardy

andydale · **Posted:** Mon May 05, 2008 5:59 am

Hi,

I agree, if you are using user managed transaction where you have control over commit time.

However if you are using full container managed transactions you really do not have full control over when the commit takes place, so i would recommend the em.merge() approach or possibly the use of @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) in this case.

Cheers,

Andy

jbchurn · **Posted:** Mon May 05, 2008 9:36 pm

My transaction begin & commit are done in the servlet filter.

Currently, I call getId() after I call persist().
Fyi, after I call persist(), I yet to call commit(). The commit is called in the servlet filter after i finish serving the jsp request.

So far it seems to be working.

Hi Hardy, can you explain what is the danger that you refer to?

hardy.ferentschik · **Posted:** Tue May 06, 2008 6:16 am

Hi,

I am basically referring to some remarks in Java Persistence with Hibernate. Hibernate's API guarantees that after a call to save() the entity has an assigned database identifier. Depending on the id generator type this means that Hibernate might have to issue an INSERT statement before flush() or commit() is called. This can cause problems at rollback time. There is a discussion about this on page 490 of Java Persistence with Hibernate.

In JPA persist() does not return a database identifier. For that reason one could imagine that an implementation holds back the generation of the identifier until flush or commit time.

Your approach might work fine for now, but you could run into troubles when changing the id generator or JPA implementation (switching from Hibernate to something else).

Maybe this is no issue for you, but I just thought I bring it up.

--Hardy