TODO solve the big problem of:
1 client A does "s 5 type foo"
2 client B does "s 5 type bar"
3 server gets client A's message
4 server gets client B's message
5 result is a conflicting state, where
When this happens,
1 the resource "5" is created with type "foo",
2 then "created again" with type "bar"
This leads to an inconsistent state, and practical bugs galore.
Another instance of this problem can be seen in technology-tests/node/06ASHAttempt_03: when you open two browser windows (clients) to the app and create some circles in client A, then create some circles in client B, creating the circles in client B has the effect of moving and recoloring the existing circles created by client A. This is because both clients created circles with id 1, 2, 3, etc., and the practical bug resulting was the apparent reclaiming of circles by different clients.
Solution: have the server give out "tickets" like at a deli counter, so maybe each clients get 50 ids for resources it can create with the GUARANTEE that it will not use an ID also used by another client. As the client uses up the unique ids and comes to a threshold where there are say 25 left, it requests 50 more from the server so there is always enough for creation of new resources. In the plausible case where no ids are left, calls to ASH.genResourceId() must wait until the server gives the client more ids. This means that ASH.genResourceId() must be made asynchronous, to account for and properly handle this rarely occurring scenario.
curran
commented
13 years ago
TODO solve the big problem of: 1 client A does "s 5 type foo" 2 client B does "s 5 type bar" 3 server gets client A's message 4 server gets client B's message 5 result is a conflicting state, where When this happens, 1 the resource "5" is created with type "foo", 2 then "created again" with type "bar" This leads to an inconsistent state, and practical bugs galore.
Another instance of this problem can be seen in technology-tests/node/06ASHAttempt_03: when you open two browser windows (clients) to the app and create some circles in client A, then create some circles in client B, creating the circles in client B has the effect of moving and recoloring the existing circles created by client A. This is because both clients created circles with id 1, 2, 3, etc., and the practical bug resulting was the apparent reclaiming of circles by different clients.
Solution: have the server give out "tickets" like at a deli counter, so maybe each clients get 50 ids for resources it can create with the GUARANTEE that it will not use an ID also used by another client. As the client uses up the unique ids and comes to a threshold where there are say 25 left, it requests 50 more from the server so there is always enough for creation of new resources. In the plausible case where no ids are left, calls to ASH.genResourceId() must wait until the server gives the client more ids. This means that ASH.genResourceId() must be made asynchronous, to account for and properly handle this rarely occurring scenario.