You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Craig Schaefer (JIRA)" <ji...@apache.org> on 2009/06/09 17:02:07 UTC
[jira] Created: (OCM-34) referential integrity problem due to
ObjectContentManagerImpl usage of ObjectCache
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.
[jira] Updated: (OCM-34) referential integrity problem due to
ObjectContentManagerImpl usage of ObjectCache
Posted by "Craig Schaefer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OCM-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Schaefer updated OCM-34:
------------------------------
Attachment: OCM-34.patch
Fix as described in original posting of this bug.
> 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
> Attachments: OCM-34.patch
>
>
> 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.
[jira] Updated: (OCM-34) referential integrity problem due to
ObjectContentManagerImpl usage of ObjectCache
Posted by "Craig Schaefer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OCM-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Schaefer updated OCM-34:
------------------------------
Status: Patch Available (was: Open)
Please review. Changes made against 1.5 branch
> 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
> Attachments: OCM-34.patch
>
>
> 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.