En general, los procedimientos no deberían comprometerse. Ese tipo de decisiones de control de transacciones deben dejarse a un código de nivel superior que sepa cuándo una transacción lógica está realmente completa. Si se compromete dentro de un procedimiento almacenado, está limitando su reutilización porque una persona que llama que quiere que los cambios que realice el procedimiento formen parte de una transacción mayor no puede simplemente llamar al procedimiento directamente.
Si llama a un procedimiento de forma interactiva, tendrá que confirmar o revertir explícitamente la transacción porque Oracle no tiene idea si piensa que la llamada al procedimiento sea una transacción lógica o si tiene la intención de componer una transacción más grande que involucre llamadas a múltiples procedimientos. Si usa dbms_scheduler
, dbms_scheduler
asume que un trabajo es una transacción lógica y se compromete al final del trabajo asumiendo que fue exitoso ( dbms_job
hace lo mismo).
Las funciones no deben manipular los datos en primer lugar. No se puede invocar una función que manipula datos desde una instrucción SQL (salvo el caso de la esquina donde se declara que la función en sí misma utiliza una transacción autónoma que casi nunca es apropiada). El punto principal de tener funciones y procedimientos es que las funciones se pueden incrustar en sentencias SQL y se pueden otorgar más libremente a los usuarios porque no cambian ningún dato.