errose28 commented on PR #6482:
URL: https://github.com/apache/ozone/pull/6482#issuecomment-2073803476
I've been able to think about this a bit more and I think a good way to
differentiate the approaches is by who manages the update ID during the write.
The two most intuitive options would be that either the client manages the
update ID (currently the second proposal), or the server manages the update ID
(not yet discussed). In the first proposal listed in the doc, both the client
and the server are managing the update ID at different parts of the operation
and I think this is why it feels "off" to me. Hopefully defining the options in
this way can clarify the differences:
- Server manages the update ID:
1. The key create request would take a flag indicating that this should
be an atomic replacement of an existing key.
2. The server saves the update ID at the time of create in the open key
table, and returns an outputstream to the client.
3. The client reads, writes, and commits the data to rewrite the same as
before.
4. The server checks the update ID saved with the open key on commit.
- Pseudocode:
```
ostream = create(/v1/b1/k1, newRepType, rewrite=true)
read /v1/b1/k1 into ostream
commit(/v1/b1/k1)
```
- Client manages the update ID (currently proposal 2 in the doc):
1. The key create request would return an outputstream to the client the
same as before.
2. The client gets the update ID of the key to overwrite.
3. The client reads and writes the data to rewrite the same as before.
4. The client commits the key, including the update ID
5. The server checks the update ID saved with the open key on commit.
- Pseudocode:
```
stream = create(/v1/b1/k1, newRepType)
genID = getInfo(/v1/b1/k1)
read /v1/b1/k1 into ostream
commit(/v1/b1/k1, genID)
```
- Client and server manage the update ID (currently proposal 1 in the doc):
1. The client gets the update ID of the key to overwrite.
1. The key create request would take this update ID and return an
outputstream to the client.
3. The client reads and writes the data to rewrite the same as before.
4. The client commits the key, the same as before.
5. The server checks the update ID saved with the open key on commit.
- Pseudocode:
```
genID = getInfo(/v1/b1/k1)
ostream = create(/v1/b1/k1, newRepType, genID)
read /v1/b1/k1 into ostream
commit(/v1/b1/k1)
```
To me, either of the first two options where only one side is responsible
for storing the update ID as the write is ongoing make sense. The third option
is a mashup of the others, which IMO is the least intuitive option. The client
reads something from the server and then immediately gives the same thing back
for the server to manage. It also unnecessarily spreads the update ID into the
client/server and server/disk protocols when it only needs to be in one or the
other.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
