[ 
https://issues.apache.org/jira/browse/JCR-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584076#action_12584076
 ] 

angela commented on JCR-1508:
-----------------------------

> The SPI implementation could throw the exception while adding the change to 
> the Batch, 
> couldn't it?

it could theoretically. but that's true for almost everything.

currently the Batch is NOT involved during the transient modifications made on 
the
jcr2spi. it only gets created once Session.save() is called.

the basic idea of the Batch was to have a temporary collection like object that 
allows
to transport a set of transient modifications within a single call to the 
persistent layer.

it never was intended to be created once transient modifications occur on the 
jcr layer.
neither was it intended to live for a longer amount of time and being involved 
with all
the potentially redundant calls on the JCR layer... including e.g. addNode and 
later
Session.refresh(false) or 'addNode' and subsequent removal.


> Setting a new property value causes a read of the previous property value
> -------------------------------------------------------------------------
>
>                 Key: JCR-1508
>                 URL: https://issues.apache.org/jira/browse/JCR-1508
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-jcr2spi
>    Affects Versions: 1.4
>            Reporter: David Rauschenbach
>
> When using JCR2SPI with a custom SPI, getProperty is called when one attempts 
> to set a new property value with disregard to the previous value. The current 
> JCR2SPI implementation causes a getPropertyInfo, which requests the old value 
> from the back-end. This is fundamentally unsound, and kills performance.
> An SPI has no choice but to guard against this by returning a PropertyInfo 
> proxy that performs lazy-loading of the value. The problem is that if an 
> error occurs when dereferencing the value, and when performing the lazy-load, 
> JCR2SPI is ill-suited to hande an unchecked exception at such a time. 
> Besides, it is a "hack upon a hack", because JCR2SPI could do this work 
> itself, by making proper use of the SPI functions for requesting property 
> type information.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to