[elephant-devel] Cached objects

[Alex Mizrahi]

 IE> If you use the discipline of using with-caching before the first read
 IE> of a cached instance's slot inside with-transaction, then you get the
 IE> following cool behavior in a multi-threaded scenario:
 IE> - txn one reads the cached values (setting read locks)
 IE> - txn one does various ops in memory
 IE> - txn one then commits the instance values (grabbing write locks)

 IE> - txn two in running in parallel and does refresh, grabbin read locks
 IE> - txn two commits after txn one and is aborted and restarted.

 IE> In this mode of operation, I believe that we can guarantee that the
 IE> ACID properties are maintained at transaction boundaries.

how is that? both txn one and two grab read locks, so they don't block each 
other, right?
then txn one modifies slots, and txn two immidiately sees changes, that 
breaks isolation, doesn't this?
only way to avoid collisions is to make even read locks exclusive, but that 
will totally kill paralellism -- even read-only transactions working with 
same objects will not be running concurrently.

i believe that "the right way" to do such stuff is thread/transaction local 
cache -- i.e. each transactions bounds *slot-cache* (e.g. hash-table), and 
all slot reads/writes work with it.
slot reads/modifications performance will be somewhat inferior, but it won't 
break concurrency.

 IE> - Slot indexing is a problem.  Completely cached slots will be out of
 IE> sync with their index because you can't keep the index in-sync with
 IE> the cached slot, so the API is broken (add instance, do query, new
 IE> instance not in query result!).  This can be fixed with a write-
 IE> through mode on the indexed slots.

partially this can be fixed by doing caching on btree level rather than on 
slot level.