sbp commented on issue #94:
URL:
https://github.com/apache/tooling-trusted-release/issues/94#issuecomment-2891582442
In order to accommodate #92, we could use a collision resistant temporary
name for the new revision directory. The context manager to create a new
revision currently passes the directory path and revision number of the new
revision to its block, so we could only use a temporary name (to avoid assuming
a new number) if none of the existing blocks used the new revision number. In
93ec427dbfeda8eb338a3fbb98db687f1e3fc95f I added some analysis of this, and
found that only one function uses the number functionally; all other uses are
for logging or spill to outside the context manager block. We can replace the
logging with "successor of {old_revision_number}". The functional use of the
new revision number is to start a new task for checks. Since that's
backgrounded anyway, that can be moved to a spill. Then the question is how to
refactor spills. We could have the contextmanager pass a Number object with
old_revision and new_revision fields, where new_revision is None during the
creati
on, and then set to the actual new_revision_number by the context manager
itself when it exits. This would remove the need for an extra call, which would
be difficult anyway without authoritative information from the context manager
because of races.
There are only two ways to resolve the context: database then directory, or
directory then database. If we write to the database first, another process
would automatically get the next revision number upon trying to allocate a
revision row, which would be ideal, except that the directory would not yet be
in place. Since everything is mediated through the database, we have to move
the directory first so that it's in place when all the queries are directed to
it. If we move the directory first, another process could try to allocate the
same directory, but it would fail. Therefore it would know that another process
is trying to claim that revision number; or has claimed it, since making the
directory is claiming a lock. The problem is that in the database case, getting
the new version number is atomic, but in the directory case, we can once again
race because we need to compute the next version number first. We would still,
therefore, have to use a lock, such as the property describe
d in the original issue text.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@tooling.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tooling.apache.org
For additional commands, e-mail: dev-h...@tooling.apache.org
