Re: [cdt-dev] EDC and asynchronous operations

["Tarassov, Eugene" <eugene.tarassov@xxxxxxxxxxxxx>]

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

This is almost always the case. It works fine. For example (I'm using
TCF definition of cache item):

TCFDataCache<Boolean> D; 
TCFDataCache<Boolean> E; 
TCFDataCache<Boolean> F;
...

TCFDataCache<Boolean> foo = new TCFDataCache<Boolean>() {
	protected boolean startDataRetrieval() {
		if (!D.validate(this)) return false;
		if (D.getData()) {
			if (!E.validate(this)) return false;
			set(null, null, E.getData());
		}
		else {
			if (!F.validate(this)) return false;
			if (F.getData()) {
				/* Validate G, H, I, J and K
concurently,
				   up to 5 commands can be sent to a
target in a single burst */
				TCFDataCache<?> pending = null;
				if (!G.validate()) pending = G;
				if (!H.validate()) pending = H;
				if (!I.validate()) pending = I;
				if (!J.validate()) pending = J;
				if (!K.validate()) pending = K;
				if (pending != null) {
					/* Does not matter which one to
wait for,
					   but waiting for last one is
usually better for performance */
					pending.wait(this);
					return false;
				}
				set(null, null, G.getData() &&
H.getData() && I.getData() && J.getData() && K.getData());
			}
			else {
				set(null, null, false);
			}
		}	
		return true;
	}
};

Note that in TCF a transaction is often implemented as cache update
function of a cache item that holds the transaction result.

Eugene.


-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of John Cortell
Sent: Tuesday, October 12, 2010 12:21 PM
To: CDT General developers list.; cdt-dev@xxxxxxxxxxx
Subject: 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. 



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev