Subspace vs key, is there any difference for FDB's key/range conflict detection?

Using FoundationDB
1

Is there any difference in terms of write/read conflict resolution between executing transaction with and without subspace, e.g:
db.Transaction( tn → tn.set( [k, e, y] , value ) ) and:
db.Subspace( [k, e] ).Transaction( tn → tn.set( [y] , value ) )

Will FDB create a conflict for [k, e, y] only in both cases? Or will Subspace transaction create key conflict for [k, e] - blocking a range instead of just the one key?

From Developer Guide — FoundationDB 7.1

FoundationDB maintains strict serializability by detecting conflicts among concurrent transactions and allowing only a non-conflicting subset of them to succeed. Two concurrent transactions conflict if the first to commit writes a value that the second reads.

Does this mean that conflicts are complete-key only and never subspace?

2

The conflict ranges should be the same–just the one key. The subspace abstraction is really just a wrapper around a byte array prefix, and then it prefixes any keys you give it with that prefix (and removes the prefix when it reads the key). So the two operations you’ve given should be identical when it comes to calls made between the client and the server.

You could, theoretically, add a conflict range over a full subspace range, but it would have to be some kind of explicit range operation (e.g., reading a full subspace, clearing a full subspace, or calling add_conflict_range over the subspace’s range).