IC68057: LOCKS ON MACH11 NODES (HDR, RSS, SDS) DO NOT RAISE ERRORS, AND ARE NOT RESPECTED.

APAR status

• Closed as program error.

Error description

• Running a 'lock table x in exclusive mode' on a MACH11 secondary
  returns no error,
  but does not lock the table.  In fact, the statement returns
  'Table locked.' making
  the client application think the table is locked.  If MACH11
  nodes 'ignore' all
  lock requests - then we should return something like 'Table lock
  ignored.', or
  'Table not locked on MACH11 secondary'.
  
  If an error is not raised, then the lock should be made.
  
  When run on the Primary node this lock is seen (partnum for the
  tab1 table is 0x1001ee):
  > lock table tab1 in exclusive mode;
  
  Table locked.
  
  $ onstat -k
  Locks
  address  wtlist   owner    lklist   type     tblsnum  rowid
  key#/bsiz
  440fe53c 0        447ed270   440fe5fc HDR+X    1001ee   0
     0
  
  This is the expected behavior.
  
  When run on the Secondary this output is seen:
  > lock table tab1 in exclusive mode;
  
  Table locked.
  
  $ onstat -k
  
  IBM Informix Dynamic Server Version 11.50.UC6DE -- Updatable
  (SDS) -- Up 21:53:41 -- 54596 Kbytes
  
  Locks
  address  wtlist   owner    lklist   type     tblsnum  rowid
  key#/bsiz
   0 active, 20000 total, 16384 hash buckets, 0 lock table
  overflows
  
  More importantly - no error message is generated.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All users using updatable secondary servers                  *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * Currently, the 'lock table' statement on secondary is a      *
  * no-op. It doesn't lock the table in the cluster and doesn't  *
  * return any error either.                                     *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Upgrade to 11.50.xC8 and above.                              *
  ****************************************************************
  

Problem conclusion

• 1) The behavior of the lock table statement will not change for
  read-only secondary server. The session issuing that statement
  will not be able to any lock the table and database server will
  not return any error back to the client. It is decided to keep
  the existing behavior for backward compatibility.
  2) A session running on an updatable secondary nodes can will
  acquire the lock when the lock table statement return success
  status.
  3) Shared mode lock  in cluster will behave same as the
  stand-alone server. After the LOCK TABLE statement executes
  successfully, other users can read the table but cannot modify
  
  
  its data until the lock is released.
  4) Exclusive mode lock requested from a secondary will behave a
  little differently. For other sessions running on a secondary
  will be able read the table but no able to update it. In short
  it will behave similar to shared access mode on secondary. While
  one session has an exclusive lock on a given table, no other
  
  
  session will be able to get shared or exclusive lock on that.
  
  Problem is first fixed in 11.50.xC8
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  IBM IDS ENTRP E

• Fixed component ID

  5724L2304

Applicable component levels

• RB15 PSY

     UP