jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 류대원 <dwo...@nhncorp.com>
Subject RE: concurrent writes
Date Tue, 06 Jan 2009 01:17:46 GMT
Right. It throws javax.jcr.InvalidItemStateException!

Sorry for giving a wrong answer...

I was confused...^^;;

Normally use lock and transactions (node has to be lockable.)

- won

-----Original Message-----
From: tcurdt@vafer.org [mailto:tcurdt@vafer.org] On Behalf Of Torsten Curdt
Sent: Monday, January 05, 2009 6:01 PM
To: users@jackrabbit.apache.org
Subject: Re: concurrent writes

>> Let's say I have two people A and B editing a node from a JCR
>> repository. Both hold a reference to the node concurrently in
>> different sessions. Both modify some properties. Now A saves his
>> session, then B saves his session. IIUC the repository would now show
>> the state of B's session as B was essentially last. Assuming the node
>> has mixin mix:versionable I would expect to revisions like
>> 1 original
>> 2 from A
>> 3 from B
>> Are these assumptions correct?
> depends on what exactly you mean with 'some properties'. if the sets of modified
> properties from A and B overlap you get an InvalidItemStateException.

Indeed that's what I meant. Let's assume A and B are both write to
property "jcr:data" or something.

> See:
> http://www.day.com/specs/jcr/1.0/

Maybe I am just reading it wrong but I still don't think this is
precisely answering the question. For one it says "The altered item in
the Session remains and may be saved later" and then "Note that this
is precisely the same situation as would arise if a change were made
to a workspace through another Session. In both cases the save on this
Session may throw an InvalidItemStateException."

> versioning is a different story. if you want to be sure that a
> modify-item/version-item sequence works without an InvalidItemStateException
> then you need to lock the item before you modify it and finally unlock it after
> you versioned it.

Right. I am currently trying to figure out when/if I have to lock and what.

>> Would there be any sign/notification (exception/return code) for B
>> that the node he wants to write to was changed by A?
> yep, the above mentioned exception.

That's the exact opposite of what Won said :)

Seems like it is time for a test case.


View raw message