querulous · HackerTrans

il y a 2 moisdiscuss

the number of doctors on j1 extensions the us is going to lose over this is going to seriously impact us healthcare. it's also not uncommon for doctors to practice on an o1 and they'll be impacted also

querulous

il y a 3 ansdiscuss

it works fine and there's someone happy to do it for free. why would anyone try to compete with it?

querulous

il y a 4 ansdiscuss

the mechanism isn't important. what apple restricts is access to any kind of cross app identifier like the idfa unless the user explicitly opts in. sketchier platforms use device fingerprinting but apple also forbids that under it's terms

the only way to do cross app tracking in ios without the user opting in and without violating apple policy is via explicitly associating accounts across apps either via oauth or some kind of account linking

querulous

il y a 10 ansdiscuss

i disagree that i don't understand martin kleppmann's method and also that his method is 'eventually consistent'.

using a random token is not equivalent to using a linearizable lock, see: https://medium.com/@talentdeficit/redlock-unsafe-at-any-time...

i am not sure what your point about delays and concurrent clients is, of course a system can't infer order from events that happen outside of it's visibility. the lock system can only provide synchronization at the point the lock is acquired

querulous

il y a 10 ansdiscuss

if your tokens come from a linearizable source (like zookeeper) you can do a compare-and-set to mutate state safely. you read the state, perform your mutations on it, then in an atomic transaction read the state again and if it is the same as the initial state save your new state. if your fencing token is the highest yet seen the service uses your state as the authorative state. if it's not it rejects the change

querulous

il y a 10 ansdiscuss

there's a formal definition but informally it means every participant agrees on an order of events in a system. if a system is linearizable you can safely compare-and-set to mutate state without introducing conflicts

querulous

il y a 10 ansdiscuss

  2. If your data store can always accept the write only if 
  your token is greater than all the past tokens, than it’s a 
  linearizable store. If you have a linearizable store, you 
  can just generate an incremental ID for each Redlock 
  acquired, so this would make Redlock equivalent to 
  another distributed lock system that provides an 
  incremental token ID with every new lock. However in the 
  next point I’ll show how this is not needed.

you confuse which system is the linearizable one in this point. your storage system is just a dumb storage system that simply returns the object version with the highest clock. what makes it linearizable to an outside observer is that the system generating the lock ids is itself linearizable. if every insert is accompanied by an authentic lock id the system is linearizable. if you generate this lock id via the storage system itself then the storage system must also be linearizable

  3. However “2” is not a sensible choice anyway: most of the times the 
  result of working to a shared resource is not writing to a linearizable 
  store, so what to do? Each Redlock is associated with a large random 
  token (which is generated in a way that collisions can be ignored. The 
  Redlock specification assumes textually “20 bytes from /dev/urandom”). 
  What do you do with a unique token? For example you can implement Check 
  and Set. When starting to work with a shared resource, we set its state 
  to “`<token>`”, then we operate the read-modify-write only if the token 
  is still the same when we write.

would you say this sequence of events is correct:

* process A acquires lock

* process B acquires a lock on the same resource after a time out and sets it's lock id on the resource

* process A sets it's lock id on the resource

* process A writes a new version of the resource

* process B attempts and fails to write a new version of the resource

if it's not correct, would you say redlock prevents it? how?

now consider what happens if the resource is only one of a group of resources that need to be transactionally updated

the bottom line is that distributed transactional locking requires linearization and redlock is plainly not linearizable. please reconsider it's continued development and steer users towards something safer like zookeeper

querulous

il y a 10 ansdiscuss

you don't need a token service if you are going to set the token on the locked resource, perform work and then unset the token. your lock is completely superfluous in that scenario

comments