0
votes

I'm unable to find documentation that fully explains entities being deleted from datastore (I'm using JDO deletePersistent) without being in a transaction. I can afford loosing data accuracy during parallel updates when not using transaction for the sake of performance and avoiding contention.

But how can i make sure when my code is running on different machines at the same time that a delete operation would not be overridden by a later update / put on a previous read to that entity on another machine, I'm letting PersistenceManager take care of implicit updates to attached objects.

EDIT: Trying to update that entity after deletePersistent will result in an exception but that is when trying to update the exact same copy being passed to deletePersistent. but if it was a different copy on another machine would be treated as updating a deleted entity (not valid) or as an insert or update resulting in putting that entity back?

2
I dont know if I understood you well but if the entity is deleted how can it be updated? It's not there anymore. - Timmo
Trying to update that entity after deletePersistent will result in an exception but that is the exact same copy passed to deletePersistent. but if it was a different copy on another machine would be treated as updating a deleted entity and hence "It's not there anymore." or insert or update resulting in putting that entity back? - blue
It's all depending on the ID. It should not care if it's the exact copy or not. It should always throw an exception if u try to update a deleted entity. It is transient after all. The data store knows nothing about it. - Timmo
That what I'm hoping for, but how can i make sure that this is the datastore behavior, the exception I'm referring to is actually being thrown from the exact detached entity it self on changing any field value and this happens before any put request is actually sent to the datastore. - blue
The datastore won't throw an exception if you try to write an entity that's been deleted, because there's no difference between an update and an insert, as far as the datastore is concerned. - Nick Johnson

2 Answers

0
votes

This is taken from GAE Documentation:

Using Transactions

A transaction is a set of Datastore operations on one or more entity. Each transaction is guaranteed to be atomic, which means that transactions are never partially applied. Either all of the operations in the transaction are applied, or none of them are applied.

An operation may fail when:

Too many users try to modify an entity group simultaneously. The application reaches a resource limit. The Datastore encounters an internal error.

Since transactions are guaranteed to be atomic, an ATOMIC operation like a single delete operation will always work inside or outside a transaction.

0
votes

The answer is yes, even after the object was deleted if it was read before and the update was being committed after delete was committed it will be put back because as @Nick Johnson commented inserts and updates are the same. tested that using 20 seconds thread sleep after getting object for update allowing the object to be deleted and then being put back.