Vidar Ramdal wrote:
> JcrModifiablePropertyMap works by storing all changes in an internal
> cache. Upon save() the cached changes are written to the
> javax.jcr.Node, and the node is save()d.
> 
> This makes sequences such as this impossible:
> try {
>   // Modify a property through PersistableValueMap
>   PersistableValueMap props = resource.adaptTo(PersistableValueMap.class);
>   props.put("prop", value);
>   props.save();
>   // Do some other, unrelated changes
>   Node sibling = resource.adaptTo(Node.class).getParent().addNode("child");
>   sibling.doSomeChange(); // This may throw an exception
>   session.save();
> } catch(Exception e) {
>   session.refresh(false); // Cancel the pending changes of this session
> }
> 
> The idea is to save all changes to the repository in one single
> session.save(). If anything fails, the session is reverted.
> This doesn't work because the properties of PersistableValueMap is not
> written to the node until PersistableValueMap.save(), and by then, it
> is too late to revert the session, as the changes of
> PersistableValueMap are already persisted.
> 
> We could make such operations easier by introducing a new method
> PersistableValueMap.write() (in lack of a better name).
> In case of JcrModifiablePropertyMap, most of save() would be moved to
> write(), leaving out node.save().
> 
> So that JcrModifiablePropertyMap.save() would be:
> public void save() throws PersistenceException {
>    this.write();
>   node.save();
> }
> 
> In the code example above, replacing props.save() with props.write()
> should give the desired functionality.
> 
I see the problem but I'm not sure what the best way of doing things is.
I think the property map uses the cache for an easy revert - if we would
do the revert differently (like caching the previous values) we could
directly set the properties on a modification and therefore a session
save would save these changes as well.
However if you call session save the property map is not aware of this
and does not get updated correctly.

So I think as soon as you mix the two worlds - the sling resource api
with value maps - and the jcr api - direct access to nodes and the
session - you sooner or later get into problems. Therefore I would
suggest to use one or the other.

Carsten
-- 
Carsten Ziegeler
cziege...@apache.org

Reply via email to