I am no transaction / database expert, so pardon my lack of knowledge within the wording here:

If you use Django's transaction.commit_on_success(func), any error that's propagated towards the charge of commit_on_success will roll back the transaction that is really useful obviously just in case you'll need some all-or-nothing action inside a method, etc. This will make Django's view-based transaction handling ideal for sights that perform a large amount of stuff.

Sometimes I wrap model techniques or common assistant functions in commit_on_success to offer the same all-or-nothing behavior.

The problem comes if you have nested Django transactions. Example: A transaction protected view calls one method that's covered with commit_on_success after which does another stuff with another model and results in the best. Oops, when control came back to commit_on_success in the model method the transaction was committed and today the vista errors out altering my view to any or all-or-some rather than all-or-nothing. This is not restricted to sights. I might have nested procedures happening which all lots_o_foo_or_nothing() uses commit_on_success and calls all_or_nothing_1() and all_or_nothing_2() that are both covered with commit_on_success. If lots_o_foo_or_nothing() errors the sub function calls may have already committed their transactions towards the DB, realistically corrupting my data.

It is possible to way for this? Again, pardon me, if I am misunderstanding something, however it appears this is actually the behavior I have observed, along with a way around it might be an excellent convenience.

not really a final solution but a concept according to this snippet (that is wise decision by itself)

this plus savepoints can make nice solution: a decorator, which is aware if transaction is inside other transaction (and when it's, is applying savepoints rather than transactions).