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
