[jira] [Commented] (SENTRY-1486) Sentry should use repeatable-read consistency level

["Alexander Kolbasov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SENTRY-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15678068#comment-15678068 ] 

Alexander Kolbasov commented on SENTRY-1486:
--------------------------------------------

Here is a bit more explanation for the problem with read-committed transaction isolation level.
I wrote a little test that demonstrates the problem. 

Here is the description of the test:

test creates 10 persistent instances of class Product each having a price of $10.
It also  creates two threads running in parallel. 
The first thread simulates a typical Sentry workflow. It walks all rows one by one and adds the price together, printing each product as it goes and the final total price (which should be $100)
The second thread simulates updates. It walks all products and for each even one it increases its price by $5 and for each odd one it decreases it by $5. This doesn't change the total price, of course.
As expected, running this program produces different results from one run to another. Sometimes I get total of 100 and sometimes 95. So the behavior is non-deterministic. The problem is that "read-committed" transactions do not prevent any changes happening between statements within transaction.

This means that in the presence of writes Sentry may produce non-deterministic results which is rather bad.

Here are code snippets:
{code}
public double total(PersistenceManager pm) {
    double result = 0.0;
    Transaction tx = pm.currentTransaction();
    tx.begin();
    for (int i = 0; i < nobjects; i++) {
        Query<Product> query = pm.newQuery(Product.class);
        query.setFilter("this.pid == :pid");
        query.setUnique(true);
        Product p = (Product)query.execute(i);
        result += p.getPrice();
        System.out.println(p);
    }
    tx.commit();

    return result;
}
{code}
public void updatePrice(PersistenceManager pm) {
    Transaction tx = pm.currentTransaction();
    tx.begin();
    // for (int i = 0; i < nobjects; i++) {
    for (int i = 0; i < nobjects; i++) {
        Product p = (Product) pm.getObjectById(prodIds[i]);
        if (i % 2 == 0) {
            p.updatePrice(5.0);
        } else {
            p.updatePrice(-5.0);
        }
    }
    tx.commit();
}
{code}
And here are a some test runs:
Run 1:
{code}
Product(11) name=Product0 [Some product] pid = 0 price 10.0
Product(12) name=Product1 [Some product] pid = 1 price 5.0
Product(13) name=Product2 [Some product] pid = 2 price 15.0
Product(14) name=Product3 [Some product] pid = 3 price 5.0
Product(15) name=Product4 [Some product] pid = 4 price 15.0
Product(16) name=Product5 [Some product] pid = 5 price 5.0
Product(17) name=Product6 [Some product] pid = 6 price 15.0
Product(18) name=Product7 [Some product] pid = 7 price 5.0
Product(19) name=Product8 [Some product] pid = 8 price 15.0
Product(20) name=Product9 [Some product] pid = 9 price 5.0
-> 1_1: 95.0000
{code}
Run 2:
{code}
Product(21) name=Product0 [Some product] pid = 0 price 10.0
Product(22) name=Product1 [Some product] pid = 1 price 10.0
Product(23) name=Product2 [Some product] pid = 2 price 15.0
Product(24) name=Product3 [Some product] pid = 3 price 5.0
Product(25) name=Product4 [Some product] pid = 4 price 15.0
Product(26) name=Product5 [Some product] pid = 5 price 5.0
Product(27) name=Product6 [Some product] pid = 6 price 15.0
Product(28) name=Product7 [Some product] pid = 7 price 5.0
Product(29) name=Product8 [Some product] pid = 8 price 15.0
Product(30) name=Product9 [Some product] pid = 9 price 5.0
-> 1_1: 100.000
{code}

> Sentry should use repeatable-read consistency level
> ---------------------------------------------------
>
>                 Key: SENTRY-1486
>                 URL: https://issues.apache.org/jira/browse/SENTRY-1486
>             Project: Sentry
>          Issue Type: Bug
>          Components: Sentry
>    Affects Versions: 1.7.0, sentry-ha-redesign
>            Reporter: Alexander Kolbasov
>            Assignee: Alexander Kolbasov
>             Fix For: 1.8.0
>
>         Attachments: SENTRY-1486.001.patch, SENTRY-1486.002.patch
>
>
> Currently Sentry uses the "read-committed" consistency level which is the default for the Datanucleus JDO library. This causes potential problems since the state visible to each transaction can actually see updates from another transactions, so it is very difficult to reason about any code that reads multiple pieces of data.
> Instead it should use repeatable read" consistency which guarantees that any transaction only sees the state at the beginning of a transaction plus any updates done within a transaction.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)