ORM Flush at end of request VS Transactions

[Jonathan Price]

I’m curious how you folks handle transactions in high level service calls? I’ve got a service call that creates a handful of related objects. This is how we had been doing it, more or less - no transactions, just ORM auto flushing at end of request.

public function create(args) {

local.obj1 = EntityNew(‘objType1’);
…set values…

EntitySave(local.obj1);

variables.svc2.create(local.obj.getID());
variables.svc3.create(local.obj.getID());
}

This worked for a while, though we’ve recently had some hard to track 'Duplicate Entry’ issues pop up - thus the question. I’m gathering that we should be working with transactions, more like this:

public function create(args) {

transaction {

local.obj1 = EntityNew(‘objType1’);
…set values…

EntitySave(local.obj1);

variables.svc2.create(local.obj.getID());
variables.svc3.create(local.obj.getID());

}
}

Which makes sense to me, but I’m running into a problem with the svc calls since the ID has yet to be created. Is there a preferred methodology for this kind of situation? I mistakenly thought I’d just be able to wrap all my service calls in transactions and call it a day. I suppose I could wrap populating local.obj1 with a transaction too, but doesn’t that defeat the purpose of a transaction that would back out all the commits if there were a problem?

Secondarily - are there good reasons NOT to keep doing it as we have been up to now. ORM flush at end of request, without transactions.

Thanks.