[elephant-devel] Cached slots and other tweaks for 1.0

Leslie P. Polzer leslie.polzer at gmx.net
Wed May 14 07:17:01 UTC 2008


> Also, cached slots are not currently thread safe.  If you don't
> guarantee that only one thread at a time is working on a particular
> object, you can get problems.  These slot values are not isolated by
> the transaction mechanism.  I'm not sure we should solve that; the
> protection for cached slots should be at a higher level so it doesn't
> swamp the benefits.

I don't know what the best decision might be here.
But I have a use case that might help; it has the following
features:

  * I access the slots of two persistent objects.

  * The number of the slots and the times requested
    together produce very bad performance (think seconds)
    even with PM txn caching (for comparison, BDB is about
    three times faster)

  * The environment is multi-threaded (web server), but the
    slots won't be changed by any other process.

  * Ideally the slots would be cached only for this one
    function and the functions called by it (and only
    per-invocation, i.e. slot caches get refreshed right at
    the beginning of the function).

  * This is currently the only place in my app where I would
    need the performance advantages of slot caching. In all
    other places ACID is highly preferred and speed is sufficient.

  * The desired behaviour can be somewhat modelled by CLSQL's
    OO interface:

      - get the objects from the DB at the beginning

      - work with those in-memory objects

      - write back the values to the DB at the end of the process

    The difference is that I don't want the whole object (other slot
    values of it might be changed from outside!) but only a few
    selected slots.

  Leslie




More information about the elephant-devel mailing list