jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Stocker <christian.stoc...@liip.ch>
Subject Re: JSOP/davex and transactions not working (compared to "simple webdav")
Date Wed, 07 Mar 2012 12:12:13 GMT
Hi

Thanks. I will read the JCR specs again about that part, but your
explanations helped a lot already. I think we might find a way for our
needs with this

greetings

chregu

On 07.03.12 13:05, Angela Schreiber wrote:
> hi chregu
> 
> if you mean 'a bunch of transient modifications' when speaking
> about transactions that everything works as expected:
> 
> you have 2 possibilities to transport a set of transient JCR
> modifications to the server:
> 
> a) LOCK (special lockscope)
>    your requests that reflect your transient modifications
>    valid methods are PUT, POST, MKCOL, ORDERPATCH, PROPPATCH
>    as far as i remember those cover the complete set of transient
>    modifications in jcr lingo.
>    UNLOCK
> 
> b) keep the transient jcr-modifications on the client-side
>    until there is a save() call on the JCR API and upon that
>    one send a single POST (later PATCH) request to the server
>    that lists the changes in the jsop diff format.
> 
> the usage of 'commit' however sound rather like real transaction
> handling... so i am a bit confused....
> 
>> I guess all the operations which are not covered by jsop-diff (like
>> checkin and copy) are anyway never part of a transaction, since they are
>> on the workspace level and not on the session level
> 
> real transactions in JCR include all operations irrespective of
> session or workspace level. the specification has a section that
> explains this in detail. but as i said before those are not
> supported by the jcr-remoting (neither client nor server) so far.
> 
> not sure, what exactly you are referring to.
> 
> kind regards
> angela
> 
>> Greetings
>>
>> chregu
>>
>>
>>
>> On 07.03.12 12:44, Angela Schreiber wrote:
>>> hi chregu
>>>
>>> the transaction type you are referring to aren't transactions s.str. but
>>> were the first version of my jcr-remoting to indentify a set of
>>> transient modifications that are transported to the server and are
>>> 'saved' at the end (or reverted with Session.refresh(false)).
>>> at that time we thought the jcr-client was really thin and would not
>>> keep transient modifications but instead immediately send them to the
>>> server (keeping as Session across multiple requests until the final
>>> save/revert is sent with the corresponding unlock request).
>>>
>>> with the creation of jcr2spi that in fact keeps track of transient
>>> modifications and the invention of the jsop diff format that concept
>>> became obsolete. in this new setup the complete set of transient
>>> changes between 2 save calls are sent to the server in a single
>>> 'batch-write' POST/PATCH request. therefore refresh(false) must not
>>> be implemented on the server-side as this is taken care off by
>>> jcr2spi (or any other jcr-client).
>>>
>>> there was an initial attempt to support transactions as defined
>>> by JSR 170 in the jcr-remoting setup but we never completed that
>>> for various reasons.
>>> there are fragments left in the jcr-server code (and for those we
>>> initially wanted to use a lock-type<jcr:global />).
>>>
>>> hope that helps
>>> angela
>>>
>>>> One thing I still get not working with using JSOP. Transactions.
>>>>
>>>> It works, when I eg. create a new Node with LOCK/MKCOL/UNLOCK, put it
>>>> doesn't with the diff format in a POST:
>>>>
>>>> In details how it worked before (the important parts)
>>>>
>>>> ***
>>>> LOCK /server/default/jcr:root HTTP/1.1
>>>>
>>>> <D:lockinfo xmlns:D="DAV:"
>>>> xmlns:jcr="http://www.day.com/jcr/webdav/1.0">
>>>>      <D:lockscope>
>>>>          <jcr:local />
>>>>      </D:lockscope>
>>>>      <D:locktype>
>>>>          <jcr:transaction />
>>>>      </D:locktype>
>>>> </D:lockinfo>
>>>> **
>>>> MKCOL /server/default/jcr:root/foo HTTP/1.1
>>>> TransactionId:<opaquelocktoken:6b78a37a-1513-4673-bd43-6a254538bd40>
>>>>
>>>> <sv:node xmlns:sv="http://www.jcp.org/jcr/sv/1.0"
>>>> xmlns:nt="http://www.jcp.org/jcr/nt/1.0" sv:name="foo">
>>>>      <sv:property sv:name="jcr:primaryType" sv:type="Name">
>>>>          <sv:value>nt:unstructured</sv:value>
>>>>      </sv:property>
>>>> </sv:node>
>>>> **
>>>> UNLOCK /server/default/jcr:root HTTP/1.1
>>>> Lock-Token:<opaquelocktoken:1a252718-18bf-40a3-ab7f-b5559c887143>
>>>>
>>>> <jcr:transactioninfo xmlns:jcr="http://www.day.com/jcr/webdav/1.0">
>>>>      <jcr:transactionstatus>
>>>>          <jcr:rollback />
>>>>      </jcr:transactionstatus>
>>>> </jcr:transactioninfo>
>>>> ***
>>>>
>>>> With the<jcr:rollback/>   at the end, that node never gets finally
>>>> created.
>>>>
>>>> But if I do exactly the same, just with a POST and :diff instead of the
>>>> MKCOL (and the LOCK/UNLOCK before/after)
>>>>
>>>> ***
>>>> POST /server/default/jcr:root/ HTTP/1.1
>>>> TransactionId:<opaquelocktoken:69125aba-3117-4a45-baf2-44e958364dc3>
>>>>
>>>> :diff=+/foo : {"jcr:primaryType":"nt:unstructured",}
>>>> ***
>>>>
>>>> That node gets created even with a rollback afterwards.
>>>>
>>>> Is this a bug? Or a missing feature? Or do transactions work
>>>> differently
>>>> here? I tried to find the problem by myself in jackrabbit-jcr-server,
>>>> but was not really successful, therefor any help would be appreciated.
>>>>
>>>> greetings
>>>>
>>>> chregu
>>>>
>>>>
>>

-- 
Liip AG  //  Feldstrasse 133 //  CH-8004 Zurich
Tel +41 43 500 39 81 // Mobile +41 76 561 88 60
www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE


Mime
View raw message