race conditions will fall-through-cache vs updates ~34

[pYr0x]

SUMMARY: With list data in localstorage, it's possible that a slow .getList shows data immediately, then a .save happens which is added to the set, but then the fall through cache updates the set.

can.fixture.delay = 5000;
can.fixture('GET /foo', function () {
    return {
        data: [
            {_id: 0, name: "messer", gruppe: 'besteck'},
            {_id: 1, name: "gabel", gruppe: 'besteck'}
        ]


    };
});

can.fixture('POST /bar', function () {
    return {_id: 5, name: "schwert", gruppe: 'besteck'};
});


Todo = can.Map.extend({});
Todo.List = can.List.extend({
            Map: Todo
        }, {});

var cache = connect(['data-memory-cache'], {});


var todoConnection = connect.superMap({
    cacheConnection: cache,
    idProp: "_id",
    Map: Todo,
    List: Todo.List,
    url: {
        getListData: 'GET /foo',
        createData: "POST /bar"
    },
    cacheLifetime: 60,
    name: 'todos'
});

Todo.getList({gruppe: 'besteck'}).then(function (todos) {
    console.log(todos.attr());
});

var foo = new Todo({
    gruppe: 'besteck',
    name: 'schwert'
});

foo.save();

if the server response take about 5 seconds, the foo.save() will execute before the data response is get by getList(). if this happens, the updateSet() in local-storage will call after foo saved and overwrite the set in localstorage

[justinbmeyer]

This will need some sort of queuing mechanism similar to can/model/queue. I think it belongs in its own behavior.

@pYr0x I'm not sure exactly who should win in a general case. Should it always be the last thing to happen or the last to respond as it is now? Maybe the behavior should simply "lock" on certain types of requests until previous ones have completed.

Let me know your thoughts. Thanks!

[pYr0x]

hey @justinbmeyer i think the locking mechanism will do the job. is can.connect working with streams? maybe we can merge that streams?

[justinbmeyer]

No. It's promise based. Switching to streams doesn't really make sense. Promise queues are easily implemented.

Sent from my iPhone

On Apr 6, 2016, at 3:32 AM, pYr0x [email protected] wrote:

hey @justinbmeyer i think the locking mechanism will do the job. is can.connect working with streams? maybe we can merge that streams?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub