[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] EDC and asynchronous operations
|
At 12:34 PM 10/12/2010, Tarassov, Eugene wrote:
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.
Right. All I'm saying is that exposing a cache item to a DSF client
in an attempt to simplify things for the client is a questionable
direction, given what I know of ACPM. If you look at the example
Pawel suggested, the benefit of exposing such an API would be that
the client can make a synchronous call instead of an
asynchronous...but it's not really that simple. The client has to
deal with the fact that the cache may be invalid. That will require
an asynchronous operation, the avoidance of which was the point of
adding the cache-based variant. Now, that's not to say ACPM doesn't
have advantages. I think it could be quite useful for a client that
needs to get a set of data points, each of which would normally
require an async operation. But as far as DSF exposing sync variants
of its services that return cache objects, the benefit is dubious to
me. Maybe there's something I'm missing.
> 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.
I understand that. But if you don't know what exactly you will need
up front, then ACPM is of little use, IMO. E.g., I may know that I
need A and B, but until I have B I don't know if I'll need C and D.
And depending on D, I may need E, or F but not both. And if F is some
particular value, then I need G, H, I, J and K. Such a use case could
probably not be properly and/or efficiently implemented using ACPM, I believe.
