JSOP in jackalope-jackrabbit
Christian Stocker
Over the last few days I added JSOP support for writing requests into
jackalope-jackrabbit. JSOP basically allows us to do all
insert/update/delete/reorder operations within one session->save in one
http POST requests. Not in many MKCOL/PUT/DELETE requests as it is now.
This can potentially save a lot of time. And makes the code even easier.
More about JSOP is here
http://dev.day.com/content/ddc/blog/2010/08/introducing_jsop.html and
http://www.slideshare.net/uncled/jsop and
https://wiki.apache.org/jackrabbit/Jsop
Unfortunately there's one remaining "big" issue. Transactions are not
supported. I sent a mail to d...@jackrabbit.apache.org
<http://www.mail-archive.com/d...@jackrabbit.apache.org/msg27927.html>
but didn't get an answer yet.
It's from one point not a big deal, since all operations within one of
those POST request are done within a transaction (so if one fails,
everyting else is rolled back), but if you want to do transactions in
your code around multiple save() calls, it's not possible right now.
Which is too bad.
That's why I removed the TransactionInterface for now from Client.php,
so the tests don't fail there. And that's why we should hold merging it
with master until I get an answer from the jackrabbit masters
But I invite everyone to test the "jsop" branch in your projects. As
long as you don't need transactions, it should work fine. If not, I'm
interested in your findings.
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
Christian Stocker
I got the answer by angela
***
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
***
It looks like we have to implement this differently. Only send the data
to the server on $utx->commit() and not on $session->save() (if there's
a transactions). Shouldn't be too hard to implement basically, but I'm
not sure, what this means in terms of jackalope and not only
jackalope-jackrabbit
chregu
Christian Stocker
***
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
***
I guess we never really supported transactions like they were intended
by JCR ;) And it's not possible with remoted-jackrabbit
Any ideas how to proceed?
chregu
Lukas Kahwe Smith
IIRC Johannes (or was it Uwe?) initially implemented this.
regards,
Lukas Kahwe Smith
sm...@pooteeweet.org
Christian Stocker
I think the main question is: How do we want to support transactions?
On the session level it would be quote easy
$utx->begin()
.. do things ..
.. do things ..
$session->save()
.. do things ..
.. do things ..
$session->save()
$utx->commit()
and only on the commit the data is sent to the server. That should be
possible, as long as we don't support transactions for workspace level
operations, like checkin and copy. I guess, we didn't support that
before either, 'cause the remoting interface of jackrabbit doesn't
support that (according to angela).
It's more the transient vs. persistence stuff, than transactions.
To build "real transaction" is just not possible with jackrabbit-remoting.
So what should we do?
1) Don't do transactions, if the backend can't really support it
2) do the cheap transactions of above
3) Fix jackrabbit so it supports transactions via remote (no idea, if
that's possible)
4) try to implement real transactions in jackalope.
I'm not sure if 2) is really worth it, because you just do the save()
later, when you want that and you have the same behaviour. and if we do
that, we should define the behaviour somehow for PHPCR.
So I vote right now for 1) and document it somehow, how you can get
"cheap" transactions nevertheless.
what are the others opinions?
chregu
>
> regards,
> Lukas Kahwe Smith
> sm...@pooteeweet.org
>
>
--
Johannes Stark
yes, it was me who implemented the transactions.
If I’m not mistaken the current behavior of Jackalope is pretty close the the case Angela described in her case a)
And I checked the JCR-WebDAV protocol spec again and I think we use the transaction mechanism the right way. See section 2.11.3 in [1]
There is just one difference/deviation: Every $session->save() is done within a transaction. This is done here: [2] And there is also an explanation why this is done. But maybe we could adjust the behavior here, to be in accordance to the spec again.
But by using JSOP things becomes different, anyway.
Regards,
Johannes
[1] http://jackrabbit.apache.org/JCR_Webdav_Protocol.doc
[2] https://github.com/jackalope/jackalope/blob/master/src/Jackalope/Session.php#L346
David Buchmann
Hash: SHA1
hi,
ah, ok. well from the jackalope point of view using what we had did work
well for implementing transactions as specified in the spec :-)
theoretically we could ignore save when inside a transaction and only do
the transport::save on transaction commit. the problem is that we leave
a lot of validation to the backend. and then we would also need to cache
workspace operations.
as angela says remoting does not support it, lets just say that for now
you don't have transactions but should take care to save only when your
operation is completed.
i guess we already did have the workspace operations not being in
transaction problem - we just did not test in a way that reveiled it. so
basically current transaction support was a lie.
everything clear? otherwise we can chat tomorrow...
cheers,david
ps: we should get rid of the auto-transaction feature and options with
the jsop transport. can you remove it chregu?
- --
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9Xma0ACgkQqBnXnqWBgIskBACfWVzh6nnVUFbd8PW9aQGQeGfN
eVAAoJNtzbTLIrX12RiN4ITGinKa9nbv
=dVdm
-----END PGP SIGNATURE-----
Christian Stocker
On 07.03.12 18:23, David Buchmann wrote:
> hi,
>
> ah, ok. well from the jackalope point of view using what we had did work
> well for implementing transactions as specified in the spec :-)
>
> theoretically we could ignore save when inside a transaction and only do
> the transport::save on transaction commit. the problem is that we leave
> a lot of validation to the backend. and then we would also need to cache
> workspace operations.
>
> as angela says remoting does not support it, lets just say that for now
> you don't have transactions but should take care to save only when your
> operation is completed.
>
> i guess we already did have the workspace operations not being in
> transaction problem - we just did not test in a way that reveiled it. so
> basically current transaction support was a lie.
I wanted to test it with current master, if it's really not supported,
but I guess it's true. But only next week, i'm off to the alps for the
next 4 days.
> everything clear? otherwise we can chat tomorrow...
>
> cheers,david
>
> ps: we should get rid of the auto-transaction feature and options with
> the jsop transport. can you remove it chregu?
auto-transaction is gone as soon as I removed the TransactionInterface
:) What do you mean with "options"?
greetings
chregu
David Buchmann
Hash: SHA1
>> i guess we already did have the workspace operations not being in
>> transaction problem - we just did not test in a way that reveiled it. so
>> basically current transaction support was a lie.
>
> I wanted to test it with current master, if it's really not supported,
> but I guess it's true. But only next week, i'm off to the alps for the
> next 4 days.
i will add tests to phpcr-api-tests transaction tests and see if we can
show its broken.
>> ps: we should get rid of the auto-transaction feature and options with
>> the jsop transport. can you remove it chregu?
>
> auto-transaction is gone as soon as I removed the TransactionInterface
> :) What do you mean with "options"?
we also have a configuration option that makes no sense now:
https://github.com/jackalope/jackalope-jackrabbit/blob/master/src/Jackalope/RepositoryFactoryJackrabbit.php#L38
cheers,david
- --
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9XtYoACgkQqBnXnqWBgIvjaACgjD/7BsJewUaLhm1PGnWgu6rQ
5bwAoMHZDP2juya/1PvCctDWITVhW1Y7
=6QGl
-----END PGP SIGNATURE-----