Re: the broken JCR locking

[Angela Schreiber]

Hi Julian

Yes... trunk only... I don't think there will be an urgent request for
backport... but I might be mistaken.

As far as the existing broken impl is concerned: I don't have a strong
opinion here. We could remove it to give room for a proper
implementation... some times it's easier to start over again than trying
to stick to something that is broken. Having said that: maybe would be
better than having dead code that is not used.

Kind regards
Angela

On 05/04/17 15:51, "Julian Reschke"  wrote:

>On 2017-04-05 15:34, Bertrand Delacretaz wrote:
>> hi Angela,
>>
>> On Wed, Apr 5, 2017 at 3:18 PM, Angela Schreiber 
>>wrote:
>>> ...Does no reply mean that everyone agrees with the proposed steps?
>>>:-)...
>>
>> I missed it but as an Oak user +1 to the below suggestion, it makes
>> things clear ;-)
>> ...
>
>I somehow missed it as well.
>
>That said, I agree that locking is broken, and making the proposed
>change will at least surface any code that relies on locking.
>
>I assume you're considering this change for trunk only? And what do we
>do with the existing incomplete implementation? Do you want to remove it
>altogether?
>
>Best regards, Julian

Re: the broken JCR locking

[Julian Reschke]

On 2017-04-05 15:34, Bertrand Delacretaz wrote:

hi Angela,

On Wed, Apr 5, 2017 at 3:18 PM, Angela Schreiber  wrote:

...Does no reply mean that everyone agrees with the proposed steps? :-)...


I missed it but as an Oak user +1 to the below suggestion, it makes
things clear ;-)
...


I somehow missed it as well.

That said, I agree that locking is broken, and making the proposed 
change will at least surface any code that relies on locking.


I assume you're considering this change for trunk only? And what do we 
do with the existing incomplete implementation? Do you want to remove it 
altogether?


Best regards, Julian

Re: the broken JCR locking

[Bertrand Delacretaz]

hi Angela,

On Wed, Apr 5, 2017 at 3:18 PM, Angela Schreiber  wrote:
> ...Does no reply mean that everyone agrees with the proposed steps? :-)...

I missed it but as an Oak user +1 to the below suggestion, it makes
things clear ;-)

> On 22/03/17 10:35, "Angela Schreiber"  wrote:
>>...That would mean that we change the corresponding repository descriptor
>>OPTION_LOCKING_SUPPORTED to return false and adjust oak-jcr to throw
>>UnsupportedRepositoryOperation upon all lock calls defined by the JCR 2.0...

-Bertrand

Re: the broken JCR locking

[Angela Schreiber]

Hi 

Does no reply mean that everyone agrees with the proposed steps? :-)

Kind regards
Angela

On 22/03/17 10:35, "Angela Schreiber"  wrote:

>Hi Oak-Devs
>
>I just had another discussion with a colleague of mine asking why JCR
>locking is not properly implemented in Oak.
>Since we have to explain that so often and explain that the implementation
>we have is not working, I would like to propose that we stop pretending
>that we support locking in Oak.
>
>That would mean that we change the corresponding repository descriptor
>OPTION_LOCKING_SUPPORTED to return false and adjust oak-jcr to throw
>UnsupportedRepositoryOperation upon all lock calls defined by the JCR 2.0.
>
>At least that would be honest about what we ship and we found find out if
>anybody actually needs locking. In case that was true, we could decide on
>how much priority implementing locking should get compared to other stuff
>on our list.
>
>wdyt?
>angela
>