I've been testing the effect of locking in version enabled tables in order to assess workspace manager restrictions when updating records in different workspaces and I have encountered a locking problem where I can't seem to update different records of the same table in different sessions if these same records have been previously updated & committed in another workspace.
I'm running the tests on 18.104.22.168. I have ROW_LEVEL_LOCKING set to ON.
Here's a simple test case (I have many other test cases which fail as well but understanding why this one causes a locking problem will help me understand the results from my other test cases):
--Change tablespace names as required
create table t1 (id varchar2(36) not null, name varchar2(50) not null) tablespace XXX;
alter table t1 add constraint t1_pk primary key (id) using index tablespace XXX;
insert into t1 values ('1', 'name1');
insert into t1 values ('2', 'name2');
insert into t1 values ('3', 'name3');
--update 2 records in a non-LIVE workspace in preparation for updating in different workspaces later
update t1 set name = name||'changed' where id in ('1', '2');
--Now in a separate session (called session 1 for this example) run the following without committing the changes:
update t1 set name = 'changed' where id = '1';
--Now in another session (session 2) update a different record from the same table. The below update will hang waiting on the transaction in session 1 to complete (via commit/rollback):
update t1 set name = 'changed' where id = '2';
I'm surprised records of different ids can't be updated in different sessions i.e. why does session 1 lock the update of record 2 which is not being updated anywhere else. I've tried this using different non-LIVE workspaces with similar results. I've tried changing table properties e.g. initrans with and still get a lock. The changes to table properties are successfully propagated to the _LT tables but not all the related workspace manager tables created for table T1 above. I'm not sure if this is the issue.
Note an example of the background workspace manager query that may create the lock is something like:
UPDATE TESTWSM.T1_LT SET LTLOCK = WMSYS.LT_CTX_PKG.CHECKNGETLOCK(:B6 , LTLOCK, NEXTVER, :B3 , 0,'UPDATE', VERSION, DELSTATUS, :B5 ), NEXTVER = WMSYS.LT_CTX_PKG.GETNEXTVER(NEXTVER,:B4 ,VERSION,:B3 ,:B2 ,683) WHERE ROWID = :B1
Any help with this will be appreciated. Thanks in advance.