Question about transactions...

Question

Halo...
I am still in a process of understanding oracle transactions and this is the question :
If I do in store procedure this:
PROCEDURE SomeProc....
varField NUMBER(15,2);
BEGIN
SAVEPOINT UndoAll;
UPDATE aTable SET aField = 1000, bField = 'YES' WHERE cField = 'id10';
SELECT aField INTO varField FROM aTable WHERE bField = 'YES' AND cField = 'id10';
EXCEPTION
WHEN OTHERS THEN ROLLBACK TO UndoAll;
END SomeProc;
Should I do COMMIT in between UPDATE and SELECT !?
Or, because it is a single transaction the SELECT statemant fetchs the changes done by previous UPDATE statemant !?

Answer 1

Should I do COMMIT in between UPDATE and SELECT !?
Or, because it is a single transaction the SELECT
statemant fetchs the changes done by previous UPDATE statemant !? When you do the UPDATE, you lock those rows. If you do not COMMIT then do a SELECT on those same rows, you'll see your updates.
If you do the UPDATE and then COMMIT, you may or may not see your changes. As soon as you commit, your locked rows become unlocked. Then anyone else may update those rows. Some of your rows may have been updated in the (very brief) time between your COMMIT and your SELECT.
Of course, in your example that's not likely to happen. But in a highly concurrent environment...who knows?
The reason you do a COMMIT is to make permanent a logical unit of work.