jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: [jr3 microkernel] Write skew
Date Wed, 30 Nov 2011 13:20:45 GMT

On 30.11.11 13:07, Felix Meschberger wrote:
> Hi,
>
> Oops, sorry, Tom just hinted at my misreading of the calculation. Of course session3
is expected to have -1 (the op is + not -).
>
> The problem here is for session2 really. What could session2 possibly do ?

The repository implementation could check whether there are certain 
read-write conflicts between session2 and session1 and throw on save if 
so. Details are here: http://dl.acm.org/citation.cfm?id=1376690

 > to a refresh before calculating ?

That would only result in a race condition since session1 might well 
save after session2 refreshed.


> Are we postulating short-lived sessions ? What about sessions backing ObservationListeners
(which are inherently long-lived) ? Do they get accurate data back ?
>
> Say, s1 listens on changes to node x, s2 updates node x and on receiving the event s1
would access the new property. What happens ?

That's a different story for a different thread ;-) In a nutshell: under 
snapshot isolation sessions will see ADD events for items which do not 
exist for them. OTHO when they get an DELETE event the item will still 
exist for them. Note how this is reverse from the situation in JR2.

Michael

>
>
> Regards
> Felix
>
> Am 30.11.2011 um 14:02 schrieb Michael Dürig:
>
>>
>>
>>> This kind of scares me a bit: What could session3 possibly do about this here
?
>>>
>>> It looks like session3 is created after everything is set and done, thus it is
expected that p1==p2==-1 and thus p1-p2==0.
>>
>> session3 can't do anything about it, session 2 could. See [1]. This is a
>> consequence inherent to snapshot isolation.
>>
>> [1] http://dl.acm.org/citation.cfm?id=1376690
>>
>>
>>>
>>> Regards
>>> Felix
>>>
>>> Am 30.11.2011 um 13:38 schrieb Michael Dürig:
>>>
>>>>
>>>> Hi,
>>>>
>>>> As documented earlier [1] new Mircokernel based JCR implementations will
>>>> most likely introduce snapshot isolation for sessions. While I think
>>>> this is a good thing in general, it also introduces potentially
>>>> troublesome write skew: application level constraints might hold locally
>>>> (i.e. per session) but might fail globally. That is, in order to enforce
>>>> some constraints, applications might need to implement explicit cross
>>>> session synchronization mechanisms instead of being able to rely on
>>>> session isolation. The following test case demonstrates the issue.
>>>>
>>>> /**
>>>>   * Trans-session isolation differs from Jackrabbit 2.
>>>>   * Snapshot isolation can result in write skew as this
>>>>   * test demonstrates: the check method enforces an
>>>>   * application logic constraint which says that the sum
>>>>   * of the properties p1 and p2 must not be negative. While
>>>>   * session1 and session2 each enforce this constraint before
>>>>   * saving, the constraint might not hold globally as can be
>>>>   * seen in session3.
>>>>   */
>>>> @Test
>>>> public void testSessionIsolation() throws RepositoryException {
>>>>      Repository repository = getRepository();
>>>>
>>>>      Session session0 = repository.login();
>>>>      Node testNode = session0.getNode("/").addNode("testNode");
>>>>      testNode.setProperty("p1", 1);
>>>>      testNode.setProperty("p2", 1);
>>>>      session0.save();
>>>>      check(getSession());
>>>>
>>>>      Session session1 = repository.login();
>>>>      Session session2 = repository.login();
>>>>
>>>>      session1.getNode("/testNode").setProperty("p1", -1);
>>>>      check(session1);
>>>>      session1.save();
>>>>
>>>>      session2.getNode("/testNode").setProperty("p2", -1);
>>>>      check(session2);  // Throws on JR2 but not on JR3
>>>>      session2.save();
>>>>
>>>>      Session session3 = repository.login();
>>>>      check(session3);  // Throws on JR3
>>>> }
>>>>
>>>> private static void check(Session session) throws RepositoryException {
>>>>      if (session.getNode("/testNode").getProperty("p1").getLong() +
>>>>          session.getNode("/testNode").getProperty("p2").getLong()<   0)
{
>>>>            fail("p1 + p2<   0");
>>>>    }
>>>> }
>>>>
>>>> Michael
>>>>
>>>> [1]
>>>> http://wiki.apache.org/jackrabbit/Transactional%20model%20of%20the%20Microkernel%20based%20Jackrabbit%20prototype
>>>
>

Mime
View raw message