GitHub user Roiocam added a comment to the discussion: Add new deleteObject functions to Persistence API
**TL;DR: NOT need to modify APIs (both user-facing or internal). If deletion or update results are ineffective, we only need to throw an exception and allow Actors to recovery states from databases for further processing.** The user API was started from [Effect](https://github.com/apache/pekko/blob/fbd36f4b33ffa762030436efe158ec94c6e4b050/persistence-typed/src/main/scala/org/apache/pekko/persistence/typed/state/scaladsl/Effect.scala#L43), there is no any API about delete in EventSourced mode, it was DurableState specific. I think we need to consider API and our promise about it. In EventSourced: - DAO(database access) shouldn't be unsuccessful, if it does, it will throw an exception and restart, rebuild state via event sourcing. - The delete method is used internally, it only calls when a snapshot is created. What about DurableState? for now: - not fully supporting CRUD, only implementing `C,R,D`, and not allowing updates. - delete should be always successful until the exception throw. Based on the known assumptions mentioned above (which may not be entirely correct), I am curious about the guarantee of deletion operations in DurableState under network partition. Before that, let's discuss network partitioning under EventSourcing: Actors will continuously increment versions, and ID + Version is a unique primary key. In case of network partition, the following scenario may occur: - Network partition occurs, and both partitions hold the in-memory state [A,9]. - Partition 2 receives a request and writes an event with ID and version [A,10]. - Partition 1 also receives a request. Since the in-memory version of A is still 9, it will also attempt to write an event with ID and version [A,10]. - At this point, there will be a primary key conflict in the database plugin. Partition 1 fails to write and needs to recovery the state [A,10] from DB. After this processing ends, it will append a new event with version 11. In EventSourced mode, data integrity is implicitly protected by the database. But what about DurableState? - Network partition occurs, and both partitions hold the in-memory state [A，9]. - Partition 2 receives a request and updates the state to [A，10]. - Partition 1 also receives a request. Since A's in-memory version is still 9 at this time when receiving new requests with inconsistent states, the resulting effect would be incorrect as well. Therefore any updates or deletions should be rejected so that Actors can recover from exceptions by reading from the database for state recovery. So I believe we might not need to modify APIs (both user-facing or internal). If deletion or update results are ineffective, we only need to throw an exception and allow Actors to recovery states from databases for further processing. GitHub link: https://github.com/apache/pekko/discussions/1233#discussioncomment-8893915 ---- This is an automatically sent email for notifications@pekko.apache.org. To unsubscribe, please send an email to: notifications-unsubscr...@pekko.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@pekko.apache.org For additional commands, e-mail: notifications-h...@pekko.apache.org
