Question

i have a quick question about objectify – this may be in the actual documentation but i haven’t found anything so i’m asking here to be safe.

i have a backend using objectify that I kind of rushed out – what i would like to do is the following – i have an event plan that is made up of activities. currently, if i delete an event i am actually writing in all of the logic to delete the individual activities inside the event plans delete method.

what i’m wondering is, if i call the activitys delete method from the event plans delete method (if it lets me do this), is it atomic?

sample (this is just pseudo code – not actual – case and method names may be wrong):

// inside event plan dao
public void delete(EventPlan eventPlan) {
  final Objectify ofy = Objectify.beginTransaction();
  try {
    final ActivityDAO activityDao = new ActivityDAO();
    for (final Activity activity : eventPlan.getActivities()) {
      activityDao.delete(activity);
    }
    ofy.getTxn().commit();
  } finally {
    if (ofy.getTxn().isActive()) {
      ofy.getTxn().rollback();
    |
  }
}


// inside activity dao
public void delete(Activity activity) {
  final Objectify ofy = Objectify.beginTransaction();
  try {
    // do some logic in here, delete activity and commit txn
  } finally {
    // check and rollback as normal
  }
}

is this safe to do? – as it is right now, the reason it’s so mangled is because i didn’t realize the entity group issue – there were certain things in the activity that were not in the same entity group as the activity itself – after fixing this i put all of the logic in the event plan delete and the method is becoming unmanageable – is it ok to break stuff down into smaller pieces or will it break atomicity.

thank you

Answer 1

Nested transactions do not happen in a single atomic chunk. There is not really any such thing as a nested transaction – the transactions in your example are all in parallel, with different Objectify (DatastoreService) objects.

Your inner transactions will complete transactionally. Your outer transaction doesn’t really do anything. Each inner delete is in its own transaction – it is still perfectly possible for the first Activity to be successfully deleted even though the second Activity is not deleted.

If your goal is to delete a group of entities all-or-nothing style, look into using task queues. You can delete the first Activity and enqueue a task to delete the second transactionally, so you can be guaranteed that either the Activity will be deleted AND the task enqueued, or neither. Then, in the task, you can do the same with the second, etc. Since tasks are retried if they fail, you can control the behavior to be sort of like a transaction. The only thing to beware of are results in other requests including the partially-deleted series during the process.