Discussion :

[Nargel33]

Bonjour,

je rencontre depuis quelque temps sur une application des problèmes de verrous.
Le caractére de ces verrous est assez aléatoire, il peut se passer une semaine sans verrou et puis il peut y en avoir 2 jours de suite.

Je n'arrive à pas déterminer si c'est la configuration de la base Oracle ou le paramétrage de forms qui pourrait être à l'origine.
Je suis sous Forms6 sur une base Oracle 9i 9.2.0.6.
Les blocs de données de tous les forms ont l'option Mode de verrouillage positionné à Automatique.
Sous Toad j'arrive à voir que le paramétre optimizer_mode est à CHOOSE

Pour moi, le verrou doit se positionner sur l'enregistrement en insert/update et non sur toute la table.
Car une fois un verrou posé sur une table suite à une action d'un utilisateur, les autres utilisateurs sont bloqués.

Faut il modifier le mode de verrouillage sous Forms, est ce le paramétrage de la base ?

D'avance merci pour votre aide.

[SheikYerbouti]

Forms ne verrouille pas la table, mais seulement la ligne en cours de modification. Bien sur, un traitement modifiant chaque ligne du bloc pourrait, locker toute les lignes de la table, mais il ne s'agira quand même pas d'un verrou de table.
N'avez vous pas des traitements, interfaces, procédures d'administration qui tenteraient de verrouiller vos tables?

[Nargel33]

A ma connaissance non. Je vais creuser de ce côté pour voir.

Concernant mon probléme, petites précisions les utilisateurs ne travaillent jamais sur les même enregistrements.

Je ne vois pas du coup, pourquoi l'utilisateur suivant, qui fait une mise à jour sur la même table, est bloqué.

[Nargel33]

Les problémes de verrous sont dûs à des lock de session, c'est la session utilisateur qui en serait à l'origine.

Quelles peuvent être les sources de ce type de verrous ?

Est ce que le fait de ne pas validé de suite le message "transaction terminée - opération enregistrée" ( apparait dans une boîte de dialogue en fin de commit), peut être une cause.

Merci

[SheikYerbouti]

Est ce que le fait de ne pas validé de suite le message "transaction terminée - opération enregistrée" ( apparait dans une boîte de dialogue en fin de commit), peut être une cause.

Merci

Absolument pas. Le commit a été effectué en base et les verous sont levés, que vous validiez cette boite de dialoge ou pas.

[strikerm59]

Vous pouvez regarder du côté des tables avec des Foreign Key sans index dessus.
J'ai eu le cas justement avec une application Forms.
Des problèmes très aléatoires, impossible à reproduire, mais au final c'était bien du à cela.
Pour information, vous pouvez vous référer au fil de discussion concernant les Foreign Key sans index :

http://www.developpez.net/forums/sho...d.php?t=451265

[taska]

FYI

investigation du coté des BITMAPS INDEXS ....

As describe above this procedure create a new tariff for the user and records are inserted into the table DEMDET_CHARGE_MATRIX, the transaction is not COMMITED ( this is normal for FORMS, the COMMIT or the ROLLBACK operations are usually done on the event EXIT_FORMS ). The transaction handles a lock on the BITMAP INDEX OBJECTS while the users stay in the screen.

CONCLUSIONS


A) Put a COMMIT after the call of the procedure DP_DEMDET_CHARGES.P_CREATE_USER_TARIFF inside the procedure PKG_DCM1_DCR1.P_KEY_NEXT_ITEM (as it’s done in the procedure PKG_DCM1_DCR1.P_MODIFY_PROPOSED_TARIFF ). However, it will be necessary to check the side effect of this COMMIT. But I think it’s should be possible because it’s done as it inside the procedure PKG_DCM1_DCR1.P_MODIFY_TARIFF.

To be sure that we have identified all the functional cases, some new tests must be done by the dev team and the functional team to check the concurrent access.

Additionally, a method could be to LOCK in the DEV environment the TABLE DEMDET_CHARGE_MATRIX and check all the INSERT, UPDATE or DELETE which are made on this table by the FORMS PFS7300, and check all potential locking issues.

B) The index BITMAP INDEX is not advised in OLTP environment. However, if we remove them we could expected some performance issues with the BATCH DEMDET.

Subject: INSERT HANGS ACQUIRING LOCK/BLOCKS OTHER INSERTS WHERE BITMAP INDEXES ARE USED
Doc ID: Note:191561.1 Type: TROUBLESHOOTING
Last Revision Date: 21-OCT-2005 Status: PUBLISHED


PROBLEM
=======
INSERT HANGS ACQUIRING LOCK THAT BLOCKS OTHER INSERTS

PROBLEM DESCRIPTION
===================

When a row is inserted into a relational table, it acquires lock and
blocks other inserts until the first insert is either committed
or rolled back

Running utllockt.sql from other session shows the following :

WAITING_SESSION LOCK_TYPE MODE_REQUESTED MODE_HELD LOCK_ID1 LOCK_ID2
--------------- ----------- -------------- --------- -------- --------
34 None
48 Transaction Share Exclusive 262239 5748

All the indexes and the constraints were checked and were proper.
There is a bitmap index on the particular table

SOLUTION
========
Remove the bitmap index and use normal index to this table and
insert the rows again.


SOLUTION EXPLANATION
=====================
Bitmap index was the cause for this lock.

Each 'entry' in a bitmap index can cover many rows in the actual table.
If 2 sessions wish to update rows covered by the same bitmap index
fragment then the second session waits for the first transaction to
either COMMIT or ROLLBACK by waiting for the TX lock in mode 4(SHARE).

When the bitmap index was removed and replaced by normal index, the
insert worked regardless of any values.

Waits due to rows being covered by the same BITMAP index fragment
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Bitmap indexes index key values and a range of ROWIDs. Each 'entry'
in a bitmap index can cover many rows in the actual table.
If 2 sessions wish to update rows covered by the same bitmap index
fragment then the second session waits for the first transaction to
either COMMIT or ROLLBACK by waiting for the TX lock in mode 4.

Eg: Ses#1: CREATE Bitmap Index tx_eg_bitmap on tx_eg ( sex );
Ses#1: update tx_eg set sex='FEMALE' where num=3;
Ses#2: update tx_eg set sex='FEMALE' where num=4;
DBA: select SID,TYPE,ID1,ID2,LMODE,REQUEST
from v$lock where type='TX';

SID TY ID1 ID2 LMODE REQUEST
---------- -- ---------- ---------- ---------- ----------
8 TX 262151 62 6 0
10 TX 327680 60 6 0
10 TX 262151 62 0 4

This shows SID 10 is waiting for the TX lock held by SID 8 and it
wants the lock in share mode (as REQUEST=4).

Ses#1: commit;
Ses#2: commit;

[Nargel33]

Bonjour,

Tout d'abord, c'ets de saison, Bonne année et meilleur voeux à tous

Je reviens sur le problème de verrous dans mon application :

un utilisateur appel un écran, celui contient un bloc basé qui retourne les informations demandées.
L'utilisateur effectue des modifications sur les données : changement de date ou de code ; mais il ne valide pas ses modifications (car il ne veut pas) et reste sur l'écran.
Ceci à déclencher un verrou (Type ROW-X(SX)) mais semble-t-il sur toute la table (??) et bloquer d'autres utilisateurs qui voulaient effectuer une modification sur cette table mais pas sur le même enregistrement.

Ce cas semble se produire lorsque l'utilisateur reste un certain temps (non meseuré) en modification sans validation sur l'écran.
J'ai tenté de reproduire le cas en restant un quart d'heure et en simulant des modifications sur la même table par d'autres transactions et sessions, sans arriver à la même conséquence

Avez vous une explication sur ce cas.

J'espére avoir été clair.

[Nargel33]

La persistence de verrous sur table, peut elle être dû à un problème de communication entre le serveur applicatif Forms et la base données.
En effet, un utilisateur valide une transaction, à son niveau tout se passe bien, mais au niveau de la base le verrou persiste et bloque les utilisateurs suivant qui veulent faire une mise à jour.

Après, cela rejoint la question de mon message précedent, pourquoi la table est verrouillée (ou semble l'être) alors que la transaction ne concerne qu'un enregistrement (sauf particularité que je ne connais pas).