Leslie,
A few of the prior messages are proof that my memory is full of holes
these days, so take this with a grain of salt! This is very
unfinished stuff. Cached operations has been tested minimally
interactively, but hasn't been verified via test suites nor used in
any significant way
> Feel free to play - Leslie I'd love to see if this fits your use
> case.
I took a look at the API, and it seems to be exactly the thing
I need (and likely beyond that!). Not sure about the naming,
though.
I'm quite amazed at the stuff you implemented in the last few weeks.
Now I only need DBP
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 par
> 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 cache
On May 12, 2008, at 10:23 AM, Leslie P. Polzer wrote:
- Currently cached slots are not rolled back to their initial value
if
transaction aborts. I can add a facility to push the cached value on
the initial read into a per-transaction list that can be used to
reset
the cached slots on an
> - Currently cached slots are not rolled back to their initial value if
> transaction aborts. I can add a facility to push the cached value on
> the initial read into a per-transaction list that can be used to reset
> the cached slots on an abort.
Would it be possible to automatically restore t
