Skip to main content

[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.

Back to the top