[
https://issues.apache.org/jira/browse/JCR-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved JCR-2780.
-
Resolution: Fixed
Best effort merge if concurrent modifications include changes to mixin types
merge if concurrent modifications include changes to mixin types
Key: JCR-2780
URL: https://issues.apache.org/jira/browse/JCR-2780
Project: Jackrabbit Content Repository
if concurrent modifications include changes to mixin types
Key: JCR-2780
URL: https://issues.apache.org/jira/browse/JCR-2780
Project: Jackrabbit Content Repository
Best effort merge if concurrent modifications include changes to mixin types
Key: JCR-2780
URL: https://issues.apache.org/jira/browse/JCR-2780
Project: Jackrabbit Content
OK,
I saw no feedback on this.
Unless there are some immediate objections, I'll thus open a ticket
against JCR2SPI inability to pass the Session.refresh() call down to the
SPI layer.
BR, Julian
Julian Reschke wrote:
OK,
sorry for getting back to this discussion late.
I modified the
OK,
sorry for getting back to this discussion late.
I modified the test case so that the InvalidItemStateException indeed
occurs with jackrabbit-core (see attachment).
I think we have consensus that JSR-170 doesn't require a store to behave
like that; it's truly optional.
Now, with the
I indeed get the expected exception, but not for
n1.getProp
n2.getProp
n1.setProp
n1.save
n2.setProp
n2.save
...which I hoped for.
i think it would be totally legitimate for a content repository to either
throw or not... personally, i would not support a test case in the
David Nuescheler wrote:
I indeed get the expected exception, but not for
n1.getProp
n2.getProp
n1.setProp
n1.save
n2.setProp
n2.save
...which I hoped for.
i think it would be totally legitimate for a content repository to either
throw or not... personally, i would not support
Yes, that is correct -- this is not about JCR compliance, but about what we
expect *Jackrabbit* to do.
ah i see... ok, my expectation would be that jackrabbit does not throw ;)
regards,
david
--
Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro
Alexander Klimetschek wrote:
Am 22.04.2008 um 20:17 schrieb Julian Reschke:
I think it's correct. The property
testconcurrent/jcr:content/jcr:data in session 2 is never put into
the transient space *before* session 1 saves. It is fetched for the
first time when you modify it. That you
Am 23.04.2008 um 13:23 schrieb Julian Reschke:
Well, the normal update cycle is *getting* the content, modifying
it, then writing it back. To be useful, that's the sequence of
operations that needs to be supported, right?
Yes, from the user point of view. But the Jackrabbit implementation
hi julian
On Tue, Apr 22, 2008 at 7:04 PM, Julian Reschke [EMAIL PROTECTED] wrote:
Hi,
I was expecting that Jackrabbit is detecting concurrent modifications to a
node, and reject them with an InvalidItemStateException.
yes, it should (and AFAIK it does ;).
However, this test:
public
Hi,
On Wed, Apr 23, 2008 at 2:45 PM, Alexander Klimetschek [EMAIL PROTECTED]
wrote:
@All: Is this a bug? Are there any test cases? WDYT?
No, it's a feature. See ConcurrentNodeModificationTest. See my previous message.
BR,
Jukka Zitting
Hi,
On Wed, Apr 23, 2008 at 2:49 PM, Stefan Guggisberg
[EMAIL PROTECTED] wrote:
the following code will trigger the InvalidItemStateException:
n1.getNode(jcr:content).setProperty(jcr:data, testcontent +
, session 1);
n2.getNode(jcr:content).setProperty(jcr:data, testcontent +
Am 23.04.2008 um 13:49 schrieb Jukka Zitting:
@All: Is this a bug? Are there any test cases? WDYT?
No, it's a feature. See ConcurrentNodeModificationTest. See my
previous message.
I don't mean his original example (where the the modifications and
saves are not interleaved). I meant the
Hi,
On Wed, Apr 23, 2008 at 3:06 PM, Julian Reschke [EMAIL PROTECTED] wrote:
So, to make this useful, a client would need to re-read the property value
before, checking it's still the same as earlier on? Is that the proposal?
Re-reading won't help as another session could still make changes
On Wed, Apr 23, 2008 at 2:09 PM, Alexander Klimetschek [EMAIL PROTECTED]
wrote:
Am 23.04.2008 um 13:49 schrieb Jukka Zitting:
@All: Is this a bug? Are there any test cases? WDYT?
No, it's a feature. See ConcurrentNodeModificationTest. See my previous
message.
I don't mean
Hi,
I have had similar problems recently. I have now a test case:
public static void main(String[] args) throws Exception {
Repository repository = new TransientRepository();
Session s1 = repository.login(new SimpleCredentials(, new char[0]));
Session s2 =
Stefan Guggisberg wrote:
According to Julian, it does not throw an exception for him. Which is a
bug.
it does throw an exception in my case.
See attached test case -- which passes over here.
Maybe it depends on config/pm settings/whatever?
BR, Julian
/*
* Licensed to the Apache Software
Hi,
On Wed, Apr 23, 2008 at 3:31 PM, Julian Reschke [EMAIL PROTECTED] wrote:
See attached test case -- which passes over here.
[...]
Session session1 = testRootNode.getSession();
Session session2 = super.superuser;
These are the same session.
BR,
Jukka Zitting
Jukka Zitting wrote:
Hi,
On Wed, Apr 23, 2008 at 3:31 PM, Julian Reschke [EMAIL PROTECTED] wrote:
See attached test case -- which passes over here.
[...]
Session session1 = testRootNode.getSession();
Session session2 = super.superuser;
These are the same session.
...
Oh well.
Hi,
I was expecting that Jackrabbit is detecting concurrent modifications to
a node, and reject them with an InvalidItemStateException.
However, this test:
public void testoverlappingUpdate() throws RepositoryException,
UnsupportedEncodingException {
String testcontent = base
Julian Reschke wrote:
...
However, this test:
...passes, although I would expect it to fail.
Sorry for the incomplete mail :-)
BR, Julian
Alexander Klimetschek wrote:
Hi Julian!
I think it's correct. The property testconcurrent/jcr:content/jcr:data
in session 2 is never put into the transient space *before* session 1
saves. It is fetched for the first time when you modify it. That you
Actually, it *is* fetched before (in the
Am 22.04.2008 um 20:17 schrieb Julian Reschke:
I think it's correct. The property testconcurrent/jcr:content/
jcr:data in session 2 is never put into the transient space
*before* session 1 saves. It is fetched for the first time when you
modify it. That you
Actually, it *is* fetched
, but I
want
to do this in such a way that it will work during concurrent
modifications.
The code I currently have is as follows ...
// Start the session
Session session = repository.login(new SimpleCredentials(admin,
admin.toCharArray()));
try
{
// Get
26 matches
Mail list logo
