On Thu, Feb 11, 2010 at 8:40 PM, Carsten Ziegeler <cziege...@apache.org> wrote:
> 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.
Exactly.
> 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.
I was hoping for a little later :)
> Therefore I would suggest to use one or the other.
Yes, but then the problem is that the resource API (which I prefer for
a lot of tasks) does not have the notion of a session, so atomic
operations as in the code above is not possible using resources.
Could we have some kind of ResourceModificationSession? Hmmm ...
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
