jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Schaefer (JIRA)" <j...@apache.org>
Subject [jira] Updated: (OCM-34) referential integrity problem due to ObjectContentManagerImpl usage of ObjectCache
Date Fri, 19 Jun 2009 15:26:07 GMT

     [ 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.


Mime
View raw message