[Zope] Need help understanding when threds get in my way

Matthew T. Kromer matt@zope.com
Mon, 30 Sep 2002 10:25:43 -0400


Dario Lopez-K=E4sten asked:

>The problem: for various reasons I need to cache several pieces of data,
>like the results form ZSQL methods, other objects, etc.
>
>Now, I understand that trying to store objects that, among other things =
are
>threadbound, is not a good idea, since they loose their context (?) when
>recalled later.
>
>The questions:
>
>a) in what other circumstances will caching objects be a bad idea?
>

Its good until cached data is invalidated by another thread.  For=20
example, let's consider:

Thread 1:  SELECT amt FROM payroll WHERE userid=3D'DLK' (saved to cache)
                 ...
Thread 2: UPDATE payroll SET amt=3Damt*1.07 WHERE userid=3D'DLK'
Thread 1:  ... (exit)
Thread 2:  ... (exit)
Thread 1: SELECT amt FROM payroll WHERE userid=3D'DLK'
                (uses cached result)

Eep, if that costing you money, you'd be upset about cache.

However, if "amt" was "taxamt" you'd probably be thrilled -- until the=20
revenue service came looking for you.

So caching tends to be problematic in the presence of updates.

One approach is to cache based on table, and purge caches on update of=20
that table.  Another is to clear thread caches after each transaction.

>b) Is there a way to test, for a given object, if it is threadbound,
>   either directly or indirectly? This I need mostly for logging
>   purposes, since it will let me identify the places where our app
>   is malfunctioning.
>

Objects in Zope *cannot* be bound to a particular thread; Python has no=20
way of making thread bindings!  Zope does maintain a copy of objects on=20
a per-thread basis -- each object from the ZODB will be loaded=20
separately for each service thread in Zope.  The only way to commingle=20
objects between threads is to do it at the module level with explicit=20
coding.  Please observe though, that loading a copy of an object doesn't=20
bind it to a thread -- it is simply not available to other threads under=20
normal circumstances because they do not have a reference to it.

>c) if I discover or suspect that an object might be problematic,  is
>   there a way to only access that objects "data" and nothing else?
> =20
>

I dont know what this means...  it sounds as if you are asking "can I=20
load the state of this object without activating the object?"  The=20
answer is, yes, you could, if you were very clever.  In practice, it=20
would be a nearly impossible job to get right.

>Thanks for any insight (including the ona that states that I make no sen=
se
>at all ;).
> =20
>


--=20
Matt Kromer
Zope Corporation  http://www.zope.com/=20