trafodion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selva Govindarajan <>
Subject RE: NATableDB (NATable cache)
Date Thu, 08 Jun 2017 20:14:38 GMT
It depends upon what context you are referring to.  There is only NATable one cache per compiler
context (CmpContext is the class). But the execution context (ContextCli is the class) can
have two or more CmpContext. - One is user query CmpContext that has the cache of user tables
and the other is metadata CmpContext that has the cache of metadata tables. In addition, I
have seen a third CmpContext at times.  However, when user application issues query against
meta data tables, I believe metadata tables involved in the query would be cached in the user

Yes. NATable cache lives as long as the CmpContext. But some of the DDL commands would invalidate
the NATable entry corresponding to the table involved in the DDL. There is also a CQD TRAF_RELOAD_NATABLE_CACHE
that can invalidate all the tables involved in the subsequent query and refresh those NATable

The CmpContext lives as long as the ContextCli.  Most often there is only one ContextCli -
a default Context in a process. The default Context lives as long as the process. However,
in case of Type 2 jdbc application, there can be as many ContextCli as the number of JDBC
connections.  These contexts (both execution and the compiler contexts) go away when the connection
is closed.

I wish I had simple answer to your question 1.


-----Original Message-----
From: Dave Birdsall [] 
Sent: Thursday, June 8, 2017 11:29 AM
Subject: RE: NATableDB (NATable cache)

And as soon as I hit "send", I think I found some answers (to questions 2 and 3 anyway).

In the second NATableDB::get function, right after inserting an NATable object in the cache,
there is logic like this:

       //insert into cache
                insert(table);  <-- sticks an object in the cache, whether or not it is

      //if we are using the cache
      //if this NATable object is cacheable
      if((useCache_) &&
          ... do a bunch of stuff such as maintain high water marks ...
        //this has to be on the context heap since we need
        //it after the statement heap has been remove
        ExtendedQualName * nonCacheableTableName = new(CmpCommon::contextHeap())
        //insert into list of names of special tables

        // insert into list of non cacheable table idents.  This
        // allows the idents to be removed after the statement so
        // the context heap doesn't keep growing.
        const LIST(CollIndex) & tableIdList = table->getTableIdList();
        for(CollIndex i = 0; i < tableIdList.entries(); i++)

So, the answer is, everything gets cached. But after the statement heap is destroyed, we come
back to NATableDB somehow and remove all the entries that were allocated from the statement
heap. For this to work correctly, however, this invariant relation must be maintained: (NATable
was allocated on statement heap) if and only if (((useCache_) && (corrName.isCacheable()))

(Maybe it would be simpler and more robust to just check which heap the NATable object was
allocated on instead.)



From: Dave Birdsall
Sent: Thursday, June 8, 2017 11:21 AM
Subject: NATableDB (NATable cache)

Hi Trafodion developers,

I'm debugging some issues pertaining to NATable descriptors, and need to understand the behavior
of the NATable cache (that is, NATableDB). I can figure it out from the code, but it might
be faster to pick the collective Trafodion brains.

Some questions about NATableDB:

  1.  I have the impression that one NATableDB exists per context, and it lives as long as
the life of the context. Is this true?
  2.  It looks like NATable objects might be created on the statement heap or on the context
heap. It looks like both may be cached. Is this true?
  3.  Assuming "yes" on question 2, how do the ones created on the statement heap get removed
when the statement heap itself is destroyed?



View raw message