db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Trivial Update of "DataDictionaryCaching" by BryanPendleton
Date Sat, 02 Sep 2006 15:59:52 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by BryanPendleton:
http://wiki.apache.org/db-derby/DataDictionaryCaching

The comment on the change is:
Fix bold markup

------------------------------------------------------------------------------
   * it consumes a certain amount of memory
   * accessing SystemTables information from the cache is vastly more efficient than reading
it from the real tables.
   * DDL statements cause the cache(s) to be flushed
-  * a DDL statement in a transaction effectively disables the cache for *all* users until
the transaction commits
+  * a DDL statement in a transaction effectively disables the cache for '''all''' users until
the transaction commits
  
  For debugging, consider the following example: DERBY-1724 is an interesting case of a situation
in which DataDictionary caching plays a role. DERBY-1724 was a manifestation of DERBY-1583,
which was an underlying bug involving an incorrect assumption about the {{{ColumnDescriptor}}}
object. A {{{ColumnDescriptor}}} object may or may not have an internal pointer to a corresponding
{{{TableDescriptor}}} object. When a {{{ColumnDescriptor}}} is first created by {{{SYSCOLUMNSRowFactory}}},
it does not have a {{{TableDescriptor}}} pointer. This is because not all {{{ColumnDescriptor}}}
objects are necessarily tied to particular tables; some may be expressions computed at runtime,
for instance. At the point where {{{FromBaseTable}}} determines that a particular {{{ColumnDescriptor}}}
is definitely tied to a particular {{{TableDescriptor}}}, it sets the table descriptor pointer
in that {{{ColumnDescriptor}}}. Since {{{ColumnDescriptor}}} objects are cached, this updated
object rema
 ins in memory for subsequent use. This means that code which uses the {{{ColumnDescriptor}}}
may or may not find that the table descriptor pointer has already been set, depending on whether
or not the cache has managed to retain the descriptor in memory since the pointer was set.
And, to close the chain of logic, the DERBY-1724 bug script contains a DDL statement (GRANT)
in a transaction, which causes the cache to be disabled and thus enables the conditions for
the DERBY-1583 bug to be triggered.
  

Mime
View raw message