That might be a better approach than what I have now. I'll think
about this. Thank you for the suggestion!
Ian
On May 14, 2008, at 3:17 AM, Leslie P. Polzer wrote:
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
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
