Disabling Statement Cache

Posted by George Potemkin on 27-Jun-2016 09:19

_Connect-CachingType can be used to enable and disable Statement Caching for client's sessions. Zero value will turns off caching if it was enabled (zero value is displayed as "?").

But in fact if Statement Caching was enabled you can't completely turns off its side effects without db restart.

Connect any database (empty, sports whatever) and run the following code:

DEFINE VARIABLE vInitUsrLocks LIKE _Latch._Latch-Lock NO-UNDO.
DEFINE VARIABLE vCurrUsrLocks LIKE _Latch._Latch-Lock NO-UNDO.

FUNCTION UsrLocks RETURN INT64:
  FOR FIRST DICTDB._Latch NO-LOCK
      WHERE DICTDB._Latch._Latch-Id EQ 3:
    RETURN  DICTDB._Latch._Latch-Lock.
  END.
END FUNCTION. /* UsrLocks */

ASSIGN vInitUsrLocks = UsrLocks().

FOR EACH DICTDB._Connect
   WHERE DICTDB._Connect._Connect-Type EQ "SELF":U:
  
  ASSIGN vCurrUsrLocks = UsrLocks().

  ASSIGN DICTDB._Connect._Connect-CachingType = 0. /* = 1 or 2 */

  DISPLAY 
    DICTDB._Connect._Connect-Usr               LABEL "Usr"
    DICTDB._Connect._Connect-CachingType       LABEL "Type"
    DICTDB._Connect._Connect-CacheLastUpdate   LABEL "Date"
    vCurrUsrLocks - vInitUsrLocks FORMAT ">>9" LABEL "USR Locks"
  . /* DISPLAY */
END.

MESSAGE "End:" UsrLocks() - vInitUsrLocks
  VIEW-AS ALERT-BOX INFO BUTTONS OK.

The code does not generate the USR latch locks.
Then enable Statement Caching by assigning value 1 or 2 to the _Connect-CachingType field.
The code will generate 6 USR latch locks (per each self-service session connected to a database).

Now disable Statement Caching by assigning 0 to the _Connect-CachingType field.
The code will generate 18 USR locks.

Run the code again and it will persistently generate 10 USR locks. If we comment out the assignment to the field then we will get 4 USR locks per each _Connect read.

You can disconnect all these sessions and start new ones. If new sessions will re-use the numbers of the previous sessions that had Statement Caching enabled then the reads of their _Connect records will still generate the USR locks.

Tested with 10.2B08, 11.6.1


Is it a bug or a feature?

All Replies

Posted by Dmitri Levin on 10-Jan-2017 16:11

George,

Statement Cache is more of a Bug then a feature. I mean it should have a label "Use it at your own risk".

When it hit a permission error as reported in KB knowledgebase.progress.com/.../000040544

all kind of wired things start to happen. The prime one is _Connect VST does not work.

For each _Connect no-lock: end. Works until it hits the user for which Statement Cache was enabled and then stops.

Promon R&D 1/18/5 Deactivate For All Users also hangs. It is probably also use _connect.

Disconnecting the user with proshut -C disconnect also does not work for that user.

The workaround ( permission fix ) works for new sessions, but not for the ones that are hanged.

We opened the case PTS CASE ID  #00383057

Posted by George Potemkin on 11-Jan-2017 06:03

Does anybody know how to release the clients blocked on STCA waits without db restart?

We can easily identify a process that caused the issue:

for each _Connect no-lock:
 display _Connect-id.
end.

It will hang on the _connect record of the corresponded session and will NOT display its details but _Connect-id of the last /displayed record/ is _Connect-Usr for the "guilty" session.

Proshut disconnect seems to be unable to disconnect the session. Will the session disconnect from database after a kill signal?

This thread is closed