-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 07.08.2011 22:06, schrieb Alexander Klimetschek: > On 15.07.11 23:09, "ChadDavis" <[email protected]> wrote: >> I'm not familiar with the transaction API for the JCR, but it's >> covered in the specification. The Session doesn't write any of it's >> changes until you session.save(). Transactions are something more >> than this. > > Session.save() is transactional in itself. The support of Java > transactions in JCR is only needed when you need to want 2-phase-commit > involving a totally different persistence mechanism.
just to be sure i did not misunderstand transactions, is this true? when doing a transaction, you can do several session.save() and any of the immediate-write workspace operations without the changes becoming visible to other sessions until you commit - or you can discard all of that in a rollback. i think the original question is not answered: what happens with concurrent updates? i would assume the proper way to prevent accidents is with locking: http://www.day.com/specs/jcr/2.0/17_Locking.html 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/ iEYEARECAAYFAk4/xfIACgkQqBnXnqWBgIt4nQCgsHtZz6EEnEzIJlmRZXJblgS6 /o8Amwetm6gh5Lk/OXZgg3vdyCE+tIXz =Jai6 -----END PGP SIGNATURE-----
