Commit question in PLSQL and Zend Framework - plsql

I would like your point of view about writing Oracle PL/SQL stored procedures and calling them in a Zend framework 3 controller.
If in my PL/SQL strored procedure I have a commit at the end of my procedure, and I use it in a controller with in proper transaction code, if there is an exception in my PHP code after calling the stored procedure, does the commit set in the database ? even if in my PHP code the rollback function is called ?

Once your PL/SQL procedure issues COMMIT, that's it. Any subsequent rollback won't have any influence on what you already committed.

Related

Achieving transaction by calling multiple procedures using Spring jdbc template

I have a scanario where i have to make multiple stored procedure calls. If any one of the stored procedures fail, i have to roll back all the procedures.
May i please know how to achieve this using spring jdbc template. What i know is that i can call only one stored procedure using the spring jdbc template.
Is there any way to invoke a group of procedures in sequence using spring jdbc template?
One way of solving this problem is to create another new stored procedure and call all the procedures in this.
Is there any other efficient way to achieve this?
Following code will call multiple stored procedures within the same transaction.
#Transactional(rollbackFor=Exception.class)
public void callStoredProcedures(){
// Stored procedure 1
//....
// Stored procedure n
}
A transaction would be initialized at the method start. All the subsequent database calls within that method will take part in this transaction and any exception within the method context would rollback the transaction.
Note that the transaction rollback for this method is configured for any Exception. By default a transaction is marked for rollback on exceptions of type RuntimeException and JdbcTemplate methods throw DataAccessException which is its subclass. If no rollback is required for checked exceptions the (rollbackFor=Exception.class) can be removed.
Also , for #Transactional annotation to work , enable transaction management. Please go through #EnableTransactionManagement

Java stored procedure running infinitely

I'm calling a java stored procedure from oracle. After i called execute() method it is never coming out of SP execution and locking the tables. But after i stop the server, the records are getting inserted into tables. Any one face similar issue?
Got the solution. Before calling the SP, i'm doing many insert and update statements and they are locking 5 to 6 tables. I committed the transaction before calling the SP and after that my SP is running fine.

Using SET_CONTEXT and SYS_CONTEXT

I have a PL/SQL package (say package1) which contains only 1 procedure. This procedure is used for security purpose and stores the application logged in user using SET_CONTEXT method.
I have another package (say package2) which contains several procedures related to application functionality but they use the SYS_CONTEXT to get the logged in user.
Whenever I want to call package2's procedures from Java, I want package1's procedure to be executed first and then package2's procedures. The reason is I want both these calls to happen in the same database connection.
Is there a way to configure this in Oracle instead of repeating the call to package1's procedure inside each and every package2's procedures.
Assuming your procedure in package1 is public (i.e., declared in the package specification), and assuming your package2 procedures have an EXECUTE authority on package1, one of the possible solutions will be using INITIALIZING PACKAGE .
The initialization consists of all the statements following the BEGIN statement at the end of the package declaration to the END statement
Ex.
PACKAGE BODY package2
IS
--All your package2 procedures
--initialization section at the end of package2:
BEGIN
package1.procedure1();
END package2;
This initialization section, will be run only the first time your session uses a package2 (by using any function/procedure in it). The package will be re-initialized in the same session if it is recompiled.
Another way to solve this problem is place code of package1 (package1.procedure1();) into user logon trigger or call that procedure from that trigger; please find example bellow for trigger
Example:
CREATE OR REPLACE TRIGGER hr_logon_trigger
AFTER LOGON
ON HR.SCHEMA
BEGIN
-- you code here or call to package1.procedure1();
END;

PL SQL Auto Commit on execution

I am very new to the PL/SQL programming. I tried to write a pl/sql procedure with some DML Statements(insert) inside the code. I am not doing any explicit commit after performing insert operations in the pl/sql code. But the transaction is getting commited after executing pl/sql procedure.
is this the default behaviour?
How can i control this?
DML statements (INSERT/DELETE/UPDATE/MERGE) don't do an auto commit in PL/SQL.
DDL statements do commit (ALTER/CREATE etc) and this will happen even if something failed. If you're running EXECUTE IMMEDIATE like dynamic statement that runs a DDL, this will also commit your transaction. And its been like that [and will remain] since 2000
Client interfaces like SQL*Plus have an auto commit feature that can be turned off/on , look for it in the client documentations. Something like
SET AUTOCOMMIT OFF
You can see the current status of this variable
SHOW AUTCOMMIT
and that will tell you whether its on/off .
Go through this for more variations of autocommit
In the PL/SQL Developer client, you control the autocommit of SQL Window transactions via Preferences.

Why does my stored procedure ignore alter constraints when called from ASP.net?

So I have a stored procedure that does the following (modified out the data params):
ALTER TABLE dbo.ReceiptInfo NOCHECK CONSTRAINT Credits_ReceiptInfo_FK1;
UPDATE ReceiptInfo SET CreditAccount=#CreditAccount WHERE CreditAccount=#OriginalAccount;
ALTER TABLE dbo.ReceiptInfo CHECK CONSTRAINT Credits_ReceiptInfo_FK1;
This is all in a stored procedure, which runs perfectly fine when I execute it from management studio but skips the alter constraints when called from ASP.net. I know it's at least executing the stored proc, because I get a message saying the update conflicted with the constraint.
For the record, I know this could all be solved by ON UPDATE CASCADE, but that option was rejected by upper management.
When you use Management Studio to execute a stored procedure, that is done under your account that presumably has admin rights.
When you execute the sp from asp.net, you probably use another account, that is not allowed to do this.

Resources