Concurrent Updates

[Ben Short <be...@benshort.co.uk>]

Hi,

How would the following scenario be best handled with JackRabbit?

I have a product node that has a stock level property. As part of a checkout
process I want to decrement the stock level property based on the number of
products the user has in their basket.

If I where using JDBC I would create a transaction, create the order, update
the stock levels then commit the transaction. If 2 transactions had updated
the stock level at the same time, the last transaction to commit would throw
an exception saying that the underlying data had changed. I could then retry
the failed transaction until it completed or there was not enough stock to
complete the other.

What will JackRabbit do if I try to modify the same node/property from
different session?

Thanks

Ben

Re: Concurrent Updates

[David Buchmann <da...@liip.ch>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 07.08.2011 22:06, schrieb Alexander Klimetschek:
> On 15.07.11 23:09, "ChadDavis" <ch...@gmail.com> 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-----

Re: Concurrent Updates

[Alexander Klimetschek <ak...@adobe.com>]

On 15.07.11 23:09, "ChadDavis" <ch...@gmail.com> 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.

Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

Re: Concurrent Updates

[ChadDavis <ch...@gmail.com>]

> If I where using JDBC I would create a transaction, create the order, update
> the stock levels then commit the transaction. If 2 transactions had updated
> the stock level at the same time, the last transaction to commit would throw
> an exception saying that the underlying data had changed. I could then retry
> the failed transaction until it completed or there was not enough stock to
> complete the other.
>
> What will JackRabbit do if I try to modify the same node/property from
> different session?
>

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.