Transaction Guard (TG) handles the concept of a knowing precisely whether a transaction committed or not. Consider the case:
a) Application issues commit request
b) It gets sent over the wire
[database or network goes KABOOM!]
The application will get an error (most probably some sort of timeout), but what they dont know is - did the commit not make it at all, or did the commit make it, but they never got the message back before the crash.
TG assigns an identifier to every committed transaction, so the logical flow in the app then becomes:
<code>
loop
do the transaction
do the commit (special ID auto assigned, TG functionality)
if ok, exit loop
if error,
reestablish connection
enquire did 'ID' commit ? (TG functionality)
if yes, then exit loop
if no, then loop around
end if;
end loop;
/code>
But that of course means you need to hand code that logic. Application Continuity (AC) sits on top of TG and does of the heavy lifting for you, but of course you need to meet the requirements/restrictions that is imposes.
Some good info here:
http://www.oracle.com/technetwork/database/database-cloud/private/transaction-guard-wp-12c-1966209.pdf http://www.oracle.com/technetwork/database/database-cloud/private/application-continuity-wp-12c-1966213.pdf