Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipselink-users] EclipseLink 1.1.3: object persisted is not considered registered at commit time

I am using the EclipseLink 1.1.3, specifically the
eclipselink-1.1.3.v20091002-r5404.zip distribution.

I have a disconnected set of new and existing objects that I want to
reattach to a clear()ed persistence manager via persist() or merge()
as appropriate, and then commit().  Basically, we have our own simple
JPA-API-based unit of work implementation which tracks changes to
disconnected objects and then reattaches and commits those objects at
an commit time.

This methodology has worked fine in the past for similar situations,
but today I'm hitting a problem where a new object which was
persist()ed is being flagged as unpersisted in
discoverAndPersistUnregisteredNewObjects() during commit().

java.lang.IllegalStateException: During synchronization a new object
was found through a relationship that was not marked cascade PERSIST:
[toString() representation of my entity].

Thread [btpool0-3] (Suspended (exception IllegalStateException))	
	RepeatableWriteUnitOfWork(UnitOfWorkImpl).discoverAndPersistUnregisteredNewObjects(Object,
boolean, Map, Map, Map) line: 4010
	OneToOneMapping(ObjectReferenceMapping).cascadeDiscoverAndPersistUnregisteredNewObjects(Object,
Map, Map, Map, UnitOfWorkImpl) line: 743
	ObjectBuilder.cascadeDiscoverAndPersistUnregisteredNewObjects(Object,
Map, Map, Map, UnitOfWorkImpl) line: 1511
	RepeatableWriteUnitOfWork(UnitOfWorkImpl).discoverAndPersistUnregisteredNewObjects(Object,
boolean, Map, Map, Map) line: 4013
	RepeatableWriteUnitOfWork.discoverUnregisteredNewObjects(Map, Map,
Map, Map) line: 206
	RepeatableWriteUnitOfWork(UnitOfWorkImpl).calculateChanges(Map,
UnitOfWorkChangeSet, boolean) line: 628
	RepeatableWriteUnitOfWork(UnitOfWorkImpl).commitToDatabaseWithChangeSet(boolean)
line: 1387
	RepeatableWriteUnitOfWork.commitRootUnitOfWork() line: 181	
	RepeatableWriteUnitOfWork(UnitOfWorkImpl).commitAndResume() line: 1060	
	EntityTransactionImpl.commitInternal() line: 84	
	EntityTransactionImpl.commit() line: 63	

This is the behavior I am seeing.  When I call persist() with this
specific object instance and trace through the code to
RepeatableWriteUnitOfWork(UnitOfWorkImpl).checkIfAlreadyRegistered, I
see that a copy of the object is already considered registered,
although not the specific instance I'm working with.  [id instance
values shown from the eclipse debugger]

Argument:
	dataEntity = com.gvea.applications.cis.entity.jpa.JpaReceiptSource  (id=2510)	


    RepeatableWriteUnitOfWork(UnitOfWorkImpl).checkIfAlreadyRegistered(Object,
ClassDescriptor) line: 765
    RepeatableWriteUnitOfWork(UnitOfWorkImpl).registerNewObjectForPersist(Object,
Map) line: 4039
    EntityManagerImpl.persist(Object) line: 255	

        if (hasNewObjects()) {
            registeredObject = getNewObjectsOriginalToClone().get(object);

Values after checking getNewObjectsOriginalToClone() map:

    this = org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork
 (id=2859)
    object = com.gvea.applications.cis.entity.jpa.JpaReceiptSource  (id=2510)	
    registeredObject =
com.gvea.applications.cis.entity.jpa.JpaReceiptSource  (id=2868)

As you can see, the copy (id=2868) is detected as registered, not the
original object being persisted.

But then when I go to commit(), I get the above IllegalStateException
for (id=2510) since the code appears to only check getCloneMapping()
and not getNewObjectsOriginalToClone() like the persist method does.
[stack trace above]

if (!isObjectRegistered(object)) {
[...]
            } else {
                // It is new but not referenced by a cascade persist
mapping, throw an error.
                throw new
IllegalStateException(ExceptionLocalization.buildMessage("new_object_found_during_commit",
new Object[]{object}));
            }

this = org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork
 (id=2859)
object = com.gvea.applications.cis.entity.jpa.JpaReceiptSource  (id=2510)


Back to the top