Database Row-Locking Problem in Objectel
(Doc ID 1105163.1)
Last updated on MARCH 30, 2023
Applies to:
Oracle Communications Objectel - Version 2.10.1 and laterInformation in this document applies to any platform.
Symptoms
To understand the problem, you might consider that:
1 - There was an external system accessing the Objectel database tables.
2 - When two or more process access a Database table can cause a row lock level due to the Transactional architecture of Oracle Database.
To avoid concurrency and consistence problems, Oracle's Database supports a powerful set of isolation level configuration. Each isolation level is defined on the terms of different concurrency/consistence problems. These phenomena/problems are listed below:
1 - Dirty Read
2 - NonRepeatable Read
3 - Phantom Read
There are four isolation level defined in ANSI/SQL. Each isolation level can avoid one or more phenomenas. The four isolation levels are:
1 - Read Uncommitted
2 - Read Committed
3 - Repeatable Read
4 - Serializable
One of the isolation levels supported by Oracle is the serializable one. The serializable level can avoid all 3 phenomena. However, it (like the same already means) will process everything in series. This means that on process will lock the row that it is processing until it finished the transaction.
For extra information about the concurrency, consistence and isolation levels please refer to:
Note that Objectel Servers uses a similar approach to keep its consistence. The approach used by Objectel is using triggers to keep each Objectel server away from another server's transaction. However, Objectel only controls its servers. It will not control external processes; this means that these processes can cause a lock into one of the internal tables that Objectel uses to do their jobs.
Changes
Cause
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
| Symptoms |
| Changes |
| Cause |
| Solution |