jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: JSOP/davex and transactions not working (compared to "simple webdav")
Date Wed, 07 Mar 2012 12:05:49 GMT
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
    as far as i remember those cover the complete set of transient
    modifications in jcr lingo.

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

> 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

View raw message