I have a JPA program where EclipseLink is the Persistence provider. When I merge an user entity, change its ID, and try to merge the same user instance again, an error is thrown. I rewrite my code to illustrate my problem in the simplest way.
User user = userManager.find(1); userManager.merge(user); System.out.println("User is managed? "+userManager.contains(user); user.setId(2); userManager.merge(user);
The above code is not in a transaction context. userManager is a stateless session bean with an EntityManager injected. When executed, the console prints:
User is managed? false Exception [EclipseLink-7251] (Eclipse Persistence Services - 2.1.3.v20110304-r9073): org.eclipse.persistence.exceptions.ValidationException Exception Description: The attribute [id] of class [demo.model.User] is mapped to a primary key column in the database. Updates are not allowed.
The exception occurs at the second merge() invocation.
If I create a new user, sets its ID and merge it, it works:
User user = userManager.find(1); userManager.merge(user); System.out.println("User is managed? "+userManager.contains(user); User newUser = new User(); newUser.setId(2); userManager.merge(newUser);
So what is the difference between the first scenario and second one? According to the JPA specification, as long as the entity is in detached state, the merge should succeed, right? (Assuming the entity with ID=2 exists)
Why the EclipseLink provider seems to be bothered by the fact that the user entity has been merged before?
Update: It seems to be an bug of EclipseLink. I have replaced the persistence provider from EclipseLink to Hibernate:
No error has been thrown.
The reason is that the
Id may be inserted/defined - as you do in your second example, but not changed/updated - as you try in your first example. The JPA provider tries to reflect the change in the database and fails.
JPA 2 spec §2.4 says
The application must not change the value of the primary key. The behavior is undefined if this occurs.