Kbase P126982: Attention: OpenEdge Database Development has Isolated a Defect in Lock Management
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
26/11/2007 |
|
Status: Verified
GOAL:
Attention: OpenEdge Database Development has isolated a defect in lock management
FACT(s) (Environment):
All Supported Operating Systems
OpenEdge 10.1B
FIX:
Dear Valued Partner and Customer,
OpenEdge Database Development has isolated a defect in lock management that is being called to your attention. While the defect requires several conditions to be present at the same time, the effect could potentially be serious. The workaround is very easy to apply. The problem only exists in OpenEdge Release 10.1B, and the fix is now available in Service Pack 3. Until you install Service Pack 3, you should use the workaround described below.
Workaround:
Add the parameter "-lkrela" (without the quotes) to your database startup command. No other change is required.
Description of the defect:
There are 5 necessary conditions for this issue to occur:
1. A client is connected to the database using shared memory (self-service)
2. That client acquires a lock outside the scope of a transaction
3. That client is killed/disconnected by an external source - either a kill signal or from a promon disconnect request
4. Additional locks owned by other user(s) are located on the same lock chain as the killed client?s lock held outside the transaction
5. The killed client's resources are cleaned up by itself, a watchdog, a server or the broker
Locks Outside a Transaction
Here is a typical ABL sequence that gets a lock outside a transaction:
FIND FIRST Customer.
DO TRANSACTION: /* or call a sub procedure or other .p or some other block reference */
FIND FIRST Order OF Customer.
UPDATE Order.
RELEASE Order.
PAUSE. /* or wait on screen I/O */
/* at this point, disconnect the user while the pause is in effect, and two of the conditions above are met. */
END.
Remaining Conditions
The two remaining conditions involve normal broker/server/watchdog housekeeping, and interactions with other clients who are deleting records. Depending on internal algorithms, there is a chance that the cleanup of the killed user's locks may additionally release locks held by a different user. This inadvertent lock release issue can result in several different problems regarding transaction isolation.
One possible outcome of the lock release above could be that crash recovery of the database may be unable to complete based on a particular order of a set of changes.
Another possible outcome could be that a change made to one record based on the isolation of another record may not be consistent if the second record's lock was inadvertently released and a different user was to then change the value of the record assumed to be held in isolation by the first user, i.e. someone else might change a record you intended to hold in a transaction.
Impact on Production
If crash recovery were to fail part way through, your database would have some uncommitted changes undone, but not others. This puts your database in an inconsistent state. If transaction isolation were to be violated in this case, transactional data relationships cannot be guaranteed.
To avoid the possible outcomes above, it is best to use the -lkrela switch on startup instead, at least until you upgrade to 10.1B03 which is available now.
If you have any questions or concerns regarding this issue, please follow up with Progress Technical Support in your region.