Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Changes between Version 7 and Version 8 of SqlobjectCaching


Ignore:
Timestamp:
03/06/08 21:08:06 (11 years ago)
Author:
Chris Arndt
Comment:

migrated

Legend:

Unmodified
Added
Removed
Modified
  • SqlobjectCaching

    v7 v8  
    1 = SQLObject Caching = 
    2  
    3 This document is based on TurboGears 0.8a4. 
    4  
    5 This document will dig into the guts of SQLObject caching to help understand what is going on in there. This level of understanding will help you to be sure that you're using caching in a way that makes sense for your application. This is based on SQLObject 0.7. 
    6  
    7 == Getting a Connection == 
    8  
    9 The TurboGears !AutoConnectHub and !PackageHub classes automatically call SQLObject's connectionForURI as needed to get a database connection. connectionForURI caches SQLObject DBConnection objects, so that only one DBConnection is maintained for a given URI. (Note: As of this writing, TurboGears works around this cache for sqlite. There is a problem with SQLObject's connection pooling for sqlite because sqlite requires that a given connection only be used on the thread on which it was created and SQLObject does not maintain this.) 
    10  
    11 The DBConnection object maintains the pool of underlying database connections and also maintains the object instance cache. DBConnection takes a "cache" parameter that is passed in to the !CacheSet object that is created (more about !CacheSet coming up). The cache parameter defaults to True. Setting this to false (?cache=0 in your connection URI) will cause items to be only "partially cached" (more below). 
    12  
    13 == CacheSets == 
    14  
    15 The !CacheSet for a DBConnection maintains a separate instance cache (!CacheFactory) for each class. 
    16  
    17 The !CacheFactory actually maintains two caches: a primary cache and an "expired" cache. The primary cache has strong references to the objects. By default, every 100 times that an item is looked up in the cache, half of the items are moved to the expired cache. The expired cache maintains only weak references. As soon as the items go out of scope elsewhere in your program, they are no longer in the cache. 
    18  
    19 == What does cache=False do? == 
    20  
    21 When you set cache=False, you may think that you're completely turning off caching. This is not the case. When cache=False, items are still put into the "expired" cache. This means that as long as the object is in scope somewhere in your program, it will appear in the cache. 
    22  
    23 In a multithreaded application (such as a typical TurboGears installation) on a busy site, it's possible that a commonly requested resource will stick around indefinitely in the expired cache even with cache=False. 
    24  
    25 == So how do I turn caching off completely? == 
    26  
    27 If you set up your class like this: 
    28  
    291{{{ 
    30 class MyClass(SQLObject): 
    31     class sqlmeta: 
    32         cacheValues = False 
     2#!rst 
     3.. note:: This page has been migrated to http://docs.turbogears.org/1.0/SqlobjectCaching 
    334}}} 
    34  
    35 that will cause SQLObject to set the class' get classmethod up to always access the database rather than using the DBConnection's cache. 
    36  
    37 There does not appear to be a way to do this globally. 
    38  
    39 == How do Transactions interact with the cache? == 
    40  
    41 Transactions have their own !CacheSet. The cache in a Transaction does not interact with the cache in the main DBConnection. This means that you may end up with stale data if you do something like this: 
    42  
    43  * pull an object from the database 
    44  * switch to a transaction 
    45  * pull the same object from the database 
    46  * update it 
    47  * commit the transaction 
    48  * access that object again outside of the Transaction 
    49  
    50 More insidious, though, is that the cache that you had outside of the Transaction will outlast single requests. So, it's possible that the stale data could show up for a few more requests before finally being dropped from the cache.