Oracle 11g v2.6 SelfService

I have an entity called Effort that is a table in Oracle. That table has about 20 fields and relates to 5 other 'bridge' tables that then link to terminal 'lookup' tables.

I have a webform that presents an interface for a user to create or edit an Effort. There are tabs for them to fill in information that corresponds to those 5 bridge tables.

Once they complete the form i ship that whole object to the server and llblgen does a great job of creating those associated 'bridge' entities and saves everything in one fell swoop - no worries.

Now a user may revisit an Effort and want to edit it slightly. I fill up the same exact form and let them have at it. I then ship that same object back to the server but this time it has a guid pk for the Effort Entity that they were editing.

My question is -when that edit gets back to the server can I just call deleteMulti on all of the associated bridge entities, delete the Effort Entity and then just call my Save method all over again?

This may not be the most efficient approach but it does work for me. I don't have concerns about anyone else 'hooking' anything off of my bridge entities so the delete is clean.

I guess the alternative would be for me to coarse over each of the submitted bridge entities that the edit user sent in, do a comparison to what was present before and what is present now, drop where needed and then add anything new they slapped on.

That is a ton of work compared to just calling DeleteMulti 5 times, EffortEntity.Delete and EffortEntity.Save.

The only issue i have with doing this right now is that I cannot get the transaction setup where it will rollback if the save fails. So if i purposefully poison the Effort Entity I get the 6 deletes and the save fails and everything is gone - not good.

If i could hammer out the transaction rollback i would be happy with the 'technical' reasons why this is not the best approach. I'm sure purists would say things like 'your fragmenting your db' or 'updates are more efficient'. But in terms of code volume the way i have it is much cleaner.

If I overlook those cons then this approach is better in my eyes. But dang that rollback. I have tried ITransaction and

Transaction transactionManager = new Transaction(IsolationLevel.ReadCommitted, "Test");

but to no avail. The one thing i have not tried yet is UnitOfWork - that's next. Here is kind of the gist of what i have now:

Transaction transactionManager = new Transaction(IsolationLevel.ReadCommitted, "Test");
            EffortEntity eff = null;
            try
            {
                EffortEntity newEffort;
                newEffort = new EffortEntity();
                newEffort = effDto.ToEntity(newEffort);
                string oldGuid = string.Empty;
                if (!string.IsNullOrEmpty(effDto.Effguid))
                {
                    oldGuid = effDto.Effguid;
                    EffortCollection ec = new EffortCollection();
                    ec.Search(effDto.Effguid);
                    eff = ec[0];

                    transactionManager.Add(eff);
                    
                    eff.EffortContact.DeleteMulti();
                    eff.EffortMeasure.DeleteMulti();
                    eff.EffortProject.DeleteMulti();
                    eff.EffortShape.DeleteMulti();
                    eff.EffortTarget.DeleteMulti();
                    bool worked = eff.Delete();
                }
                //create
                string res = string.Empty;
                res = newEffort.Save();
                if (res.ToUpper() == "TRUE")
                {
                    transactionManager.Commit();
                    return;
                }
                else
                {
                    transactionManager.Rollback();
                    return;
                }
            }
            catch
            {
                transactionManager.Rollback();
                return;
            }
            finally
            {
                transactionManager.Dispose();
            }

Any suggestions?

If you want that the collection involved in DeteleMulti be added to the transaction, you need to add it (the collection) explicitly. Example:

...

transactionManager.Add(eff);
transactionManager.Add(eff.EffortContact);
transactionManager.Add(eff.EffortMeasure);
transactionManager.Add(eff.EffortProject);
transactionManager.Add(eff.EffortShape);
transactionManager.Add(eff.EffortTarget);
    
eff.EffortContact.DeleteMulti();
eff.EffortMeasure.DeleteMulti();
eff.EffortProject.DeleteMulti();
eff.EffortShape.DeleteMulti();
eff.EffortTarget.DeleteMulti();
bool worked = eff.Delete();

...