referential integrity problem due to ObjectContentManagerImpl usage of
ObjectCache
----------------------------------------------------------------------------------
Key: OCM-34
URL: https://issues.apache.org/jira/browse/OCM-34
Project: Jackrabbit OCM
Issue Type: Bug
Reporter: Craig Schaefer
It appears that there is an ObjectCache which lives for the lifetime of an
ObjectContentManagerImpl instance. In most cases the reference to the
ObjectCache is shared with the ObjectConverterImpl (which is also contained by
ObjectContentManagerImpl).
Normally any of the ObjectContentManagerImpl #getObject(String path),
#getObjectByUuid(String uuid), #getObject(String path, String versionName)
#getObject(Class objectClass, String path, String versionName) behaviours cause
the ObjectCache to be populated by as the ObjectConverterImpl is used. At the
end of ObjectConverterImpl usage the ObjectCache is always cleared.
However if I use ObjectContentManagerImpl#retrieveAllMappedAttributes(Object
object) or retrieveMappedAttribute(Object object, String attributeName) then
the ObjectConverterImpl is also used and as a side effect the ObjectCache is
updated but never cleared.
Therefore, if I now start deleting objects and then re-adding them at the same
path the objectCache is used during the insert process and it refers to old
objects which were deleted.
e.g.
myObject = ocm#getObject(/path/to/object)
## at this point ObjectCache is empty again
ocm#retrieveMappedAttribute(myObject, "attributeName") - where attribute is
a reference to another object
## at this point ObjectCache is still populated with referencedObject
ocm#delete(myObject)
ocm#delete(referencedObject)
ocm#save()
## at this point ObjectCache is still populated with referencedObject
ocm#insert(newMyObject) - where newMyObject has same path as myObject
## at this point the ObjectConverterImpl has refered to the ObjectCache and
mapped the reference attribute to the old referencedObject in ObjectCache.
ocm#save()
## at this point the save fails due to referential integrity
The fix was to extend ObjectContentManagerImpl to fix
#retrieveAllMappedAttributes(Object object) or retrieveMappedAttribute(Object
object, String attributeName) as well as #save() to provide coverage for any
loose cases. If jackrabbit-ocm were to be updated instead the deltas to
ObjectContentManagerImpl would be:
public void retrieveMappedAttribute(Object object, String attributeName) {
objectConverter.retrieveMappedAttribute(session, object, attributeName);
+ requestObjectCache.clear()
}
public void retrieveAllMappedAttributes(Object object) {
objectConverter.retrieveAllMappedAttributes(session, object);
+ requestObjectCache.clear()
}
public void save() {
try {
this.session.save();
} catch (NoSuchNodeTypeException nsnte) {
throw new JcrMappingException("Cannot persist current session
changes. An unknown node type was used.", nsnte);
} catch (javax.jcr.version.VersionException ve) {
throw new VersionException("Cannot persist current session changes.
Attempt to overwrite checked-in node", ve);
} catch (LockException le) {
throw new ObjectContentManagerException("Cannot persist current
session changes. Violation of a lock detected", le);
} catch (RepositoryException e) {
throw new ObjectContentManagerException("Cannot persist current
session changes.", e);
+ } finally {
+ requestObjectCache.clear()
+ }
}
This fix works fine in our coverage suite.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
