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
