Isolation level SERIALIZABLE problem

Question

Hi there,
I have a problem with my stored procedures when the isolation level of the connection is serializable. I need to set this isolation level because of data consistency reasons.
When in this isolation level and a transaction tries to update or delete data modified by a transaction that commits after the serializable transaction began, I get this error:
ORA-08177: Cannot serialize access for this transaction
This is normal. The thing to do in this case is catch the error in the exception handler, rollback to a certain savepoint and try to do the update again.
The stored procedure that I use to test this is:
CREATE OR REPLACE PROCEDURE nm_test IS
tmpVar NUMBER;
err_num NUMBER;
err_msg VARCHAR2(200);
teller number;
BEGIN
teller := 0;
savepoint sp1;
<<try_every_thing_again>>
begin
tmpVar := 0;
update stock_prices set price = price + 1
where ric = 1;
DBMS_OUTPUT.Put_Line('teller = ' || teller);
EXCEPTION
WHEN others THEN
err_num := SQLCODE;
--err_msg := SUBSTR(SQLERRM, 1, 200);
     if (err_num = -8177) then
          rollback to savepoint sp1;
          --DBMS_LOCK.SLEEP(1);
          teller := teller + 1;
          if (teller < 10) then
               goto try_every_thing_again;
          end if;
          DBMS_OUTPUT.Put_Line('exception: teller = ' || teller);
     end if;
end;
END nm_test;
I test this using 2 connections to the database. In the first connection I run the stored proc (without committing). Then I run the same stored proc in the second connection. This will block on the update (the is an implicit lock), which is ok. Then I commit the first connection. The second catches the error, rolls back and tries the update again....but then it catches the exception again, and again???
When I replace the "rollback to savepoint" by just "rollback", everything works fine (the exception is then caught only once) and the update succeeds on the second try.
But I can not work with just a "rollback" because my stored procedures might be called by others for which I don't want to undo all the work.
Do any of you know why I keep getting this error (the program ends up in an infinite loop if I didn't keep a counter and exit after 10 times)?
Marcel van Vuure

Answer 1

Marcel,
First of all, I'd be interested in hearing why you think you need serializable transactions (why 'read committed' doesn't work for your application). In the 8 years I've been building Oracle apps, I've never deemed it necessary to use serializable transactions. Maybe an optimistic locking strategy will solve your problem.
Secondly, if I were designing the interface, I wouldn't have a procedure in charge of both executing business logic AND retrying the logic in case of failure. I'd build a helper procedure that calls the procedure that does the work, looks for certain exceptions, and retries the procedure when necessary.
Lastly, if your interface doesn't have transactional control (the caller is in charge of commits and rollbacks), maybe you should simply attempt the update statement and throw an exception to the caller and let them handle it.
I'm sorry if I haven't directly solved your problem, but sometimes the best way to solve a problem is to question the decisions that got you there in the first place.
Hi there,
I have a problem with my stored procedures when the isolation level of the connection is serializable. I need to set this isolation level because of data consistency reasons.
When in this isolation level and a transaction tries to update or delete data modified by a transaction that commits after the serializable transaction began, I get this error:
ORA-08177: Cannot serialize access for this transaction
This is normal. The thing to do in this case is catch the error in the exception handler, rollback to a certain savepoint and try to do the update again.
The stored procedure that I use to test this is:
CREATE OR REPLACE PROCEDURE nm_test IS
tmpVar NUMBER;
err_num NUMBER;
err_msg VARCHAR2(200);
teller number;
BEGIN
teller := 0;
savepoint sp1;
<<try_every_thing_again>>
begin
tmpVar := 0;
update stock_prices set price = price + 1
where ric = 1;
DBMS_OUTPUT.Put_Line('teller = ' || teller);
EXCEPTION
WHEN others THEN
err_num := SQLCODE;
--err_msg := SUBSTR(SQLERRM, 1, 200);
     if (err_num = -8177) then
          rollback to savepoint sp1;
          --DBMS_LOCK.SLEEP(1);
          teller := teller + 1;
          if (teller < 10) then
               goto try_every_thing_again;
          end if;
          DBMS_OUTPUT.Put_Line('exception: teller = ' || teller);
     end if;
end;
END nm_test;
I test this using 2 connections to the database. In the first connection I run the stored proc (without committing). Then I run the same stored proc in the second connection. This will block on the update (the is an implicit lock), which is ok. Then I commit the first connection. The second catches the error, rolls back and tries the update again....but then it catches the exception again, and again???
When I replace the "rollback to savepoint" by just "rollback", everything works fine (the exception is then caught only once) and the update succeeds on the second try.
But I can not work with just a "rollback" because my stored procedures might be called by others for which I don't want to undo all the work.
Do any of you know why I keep getting this error (the program ends up in an infinite loop if I didn't keep a counter and exit after 10 times)?
Marcel van Vuure