DB minter design questions about noid-rails HOT 6 CLOSED

Pessimistic. I don't see how you could have deadlock if you're locking only on a single resource.

from noid-rails.

Option 2: lock row from time of access until commit.

I don't think this will impeded the ability of the use case to scale reasonably.

from noid-rails.

@jcoyne: in the scope of this engine, I agree, it is the only thing in the DB that it cares about. In the scope of a consuming application, we can imagine transactions wrapping the minter action that add scope. But the locking logic can be compact and distinct.

If consensus is for pessimistic locking (fine by me), then what failsafe makes sense? Timeout of 10 seconds? None?

from noid-rails.

@atz any downside to choosing "none" for now, 'til we know what we're dealing with?

from noid-rails.

Random catastrophic failure under load. Other than that, no....

from noid-rails.

I call that "Tuesday."

from noid-rails.