[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] EDC and asynchronous operations
|
Hi John,
> Interesting idea...using ACPM for client access. But I'm not sure how
practical that would be. Clients using such access would be unreliable,
right? If the cache is invalidated, the client is screwed unless it has
a plan B to use the asynchronous calls. And coding something to try one
way (simple), then another if needed (harder) isn't really a
simplification. Then again, perhaps I'm misunderstanding your
suggestion. Or perhaps you're thinking of situations where the client is
willing to abort the request altogether if the cache is invalid (even
though real-time data could be obtained)
If a client encounter an invalid cache item, it can choose:
1. Abort the transaction and return an error.
Or 2. Start data retrieval on the item, add the transaction to the wait
list of the item, re-run the transaction when item state changes.
Most clients choose #2.
> But, again, it seems useful only when you know up front exactly what
set of data points you need for the transaction.
Not sure what you mean. A transaction code decides at run time what data
points to accesses. In fact, this is one of biggest benefits of ACPM:
you can write transaction code as traditional sequential code, using
'if' and 'for' statements, recursive calls, etc., and access all cached
data as normal variables, without programming call-backs for every data
access. But to be able to do that, you need to wrap into cache items all
your remote data and everything derived from remote data, and various
getSomething functions need to return cache item instead of actual data.
Regards,
Eugene
