After evicting an entity, should it be possible to create a new entity with the exact same xt/id?
Asked another way: itâs possible to put an entity with an id that was previously evicted. Is it OK if I rely on this behavior?
Reason for asking: Iâm thinking of replacing an evicted user-entity with an âanonymousâ entity (user name and email removed, but company name still there) so when I look at the history of other entities, I can still see which company did what change.
Hey @xpekeler reusing evicted IDs is possible currently, however, it may be subject to race conditions if you âreplaceâ the evicted entity too quickly after the eviction, see: Race Condition for Eviction Tombstone ¡ Issue #432 ¡ xtdb/xtdb ¡ GitHub
Also note that you canât evict and re-put within the same transaction, see: xtdb/tx_test.clj at 7ec4828f48b3fb97ffd1baf4eda22857c9fcb48d ¡ xtdb/xtdb ¡ GitHub and evict then re-put to the same entity in the same transaction is broken ¡ Issue #1337 ¡ xtdb/xtdb ¡ GitHub
Therefore as general advice right now, we would recommend to avoid resurrecting an evicted entity whilst those issues remain unresolved. That said, Iâd be happy to try to help you reason about how to avoid the race condition
Thanks. Waiting for the evict transaction wouldnât be enough to avoid the race-condition? What else could I be waiting for between eviction and put? (Weâre using Postgresql & RocksDB, if that makes a diffeerence)
Actually I think that would be enough, but the trouble is knowing when an eviction operation has been submitted in the first place - like maybe you would need some other store/queue/service to handle this in reliable/scalable way. Or maybe itâs straightforward and safe enough if you are always funnelling such eviction requests through a single submitting node
Thanks. Upon further thought, since I donât even know how to detect the race condition, nor have any idea about the potential consequences, I decided to use a different approach. Now, when an entity is evicted, a new replacement-entity is created that gets its own id but has a :replaces-id with the evicted entityâs id. At runtime, when an association canât be resolved, the replacement-entity is looked up and used in place of the evicted entity. Not as fast & clean as the original approach, but I prefer having higher confidence about this