You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Ard Schrijvers (JIRA)" <ji...@apache.org> on 2012/06/27 16:55:44 UTC

[jira] [Updated] (OCM-34) referential integrity problem due to ObjectContentManagerImpl usage of ObjectCache

     [ https://issues.apache.org/jira/browse/OCM-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ard Schrijvers updated OCM-34:
------------------------------

    Resolution: Fixed
      Assignee: Ard Schrijvers
        Status: Resolved  (was: Patch Available)

applied patch
                
> 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
>            Assignee: Ard Schrijvers
>         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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira