Increasing INITRANS will help to achieve higher concurrency, but it must be done on the table and all its indexes, and the ORA-08177 error can still occur, in cases where a row you're trying to update has been already modified by a different transaction. Edit: creating the table in ROWDEPENDENCIES mode might also help, I believe.
The only cure for the ORA-08177 error is to rollback changes and re-run the entire business transaction. If there are no update collision on the next run, the transaction will finish.
The important thing is that the entire business transaction (its complete logic) has to be re-run. The typical scenario can be easily described on a banking account. Let's say that we have an account with a balance of $100, and there are two processes (business transactions) trying to subtract $75 each from that account. This is how the timing might work like:
Transaction 1: starts serializable transaction (all data read from the database will correspond to the state of the database at this moment)Transaction 2: starts serializable transaction (all data read from the database will correspond to the state of the database at this moment)------T1: reads the ballance of the account (sees $100)T1: compares the account to the amount to subtract ($75) - there is enough money, so the transaction proceedsT1: updates the account in the database: subtracts $75. The current balance is $25T1: commits------T2: reads the ballance of the account (sees $100, even though the T1 has already committed, because the transaction is serializable)T2: compares the account to the amount to subtract ($75) - there is enough money, so the transaction proceedsT2: tries to update the account in the database. Since it was modified by T1, ORA-08177 is thrown.------T2 restarts the entire processT2: rollback (important!)T2: starts serializable transaction (all data read from the database will correspond to the state of the database at this moment)T2: reads the ballance of the account (sees $25)T2: compares the account to the amount to subtract ($75) - there is not enough money, so the transaction doesn't proceed, but informs the client that there are not enough money on the account.T2: rollback (important!)
Hopefully this scenario illustrates how serializable isolation level help to protect the integrity of the data. The exact order of individual statements can be different. The important thing is that the first transaction that updates the row gets through, while the second transaction fails with ORA-08177.
I'd say that you'd really benefit from reading the
Oracle's Concepts Guide (this is for version 11.2, google for the guide of your version if you're using another). Developing a banking application requires very good understanding of the processing in the database, in my opinion, and Concepts Guide is an excellent introduction into it.