Darren, I generally agree with you... just trying to point out what could be pitfalls on the way to evolve the system.
On Oct 9, 2013, at 10:29 AM, Darren Shepherd wrote: > > I wish we were doing transaction per API, but I don't think that was > ever a consideration. I do think the sync portion of API commands > should be wrapped in a single transaction. I really think the > original intention of the Transaction framework was to assist in > cleaning up resources that people always forget to close. I think > that is mostly it. My understanding is that for instance when a VM is created you have a call flow that looks a bit like: 1. UserVmManagerImpl.createVirtualMachine (@DB, persist) 2. VirtualMachineManagerImpl.allocate (@DB, persist) 3. NetworkOrchestrator.allocate (@DB, persist) My understanding is that an check in NetworkOrchestrator (e.g. nic parameters not being kosher) is supposed to rollback the transaction and remove the VM in the database... There are some errors for which this mechanism works OK today.... I believe it would be desirable to have a proposal of how to deal with such an example and then attempt to implement it consistently. Even if it requires the programmer to understand that it needs to explicitly rollback the VM if the underlying layers throw an exception. Pedro.
