Do not rely on a frontend instance's RAM-cache. The instances do not share
RAM and the only way you can directly address a particular instance is
using a front-facing backend, as noted by Gerald.
The trouble is, even if you could safely store all your ints in addressable
RAM space, you are going to need code synchronization on your variables and
maps/lists to avoid CoMod exceptions.
This is not only painful to code, if every method is synchronizing on a
single map of values, you effectively lose all ability to run in parallel
and will probably be slower than single threaded.
If you want to take advantage of threadsafe {you REALLY want to take
advantage of threadsafe}, you need every request to be servable from
instance scope. That is, using as few static vars / servlet instance vars
as possible {servlets are singletons, remember!}
Honestly though, I don't think you even need either ram or ds... Maybe not
even memcache.
I will describe for you one possible scenario to do this efficiently; you
don't have to take my advice, but here it is:
If, instead of having client B poll for the fifo data, you use the channel
api / url fetch to push messages directly from client A to client B.
Instead of making client A save to appengine, then have client B get from
appengine, just use appengine to let client A save to client B.
If the client is in a web browser, use the channel api to push messages
{frontends only, no backend support yet}.
If the client is a web server, use url fetch to push the data.
If client A is writing ints in batches, you can just send those ints in
batches. A serialized CSV string makes very good sense here.
Should you have any trouble with the channel api, you may want to keep
copies of your int frames in memcache.
You can rely on messages going through most of the time, but if client B is
expecting data and doesn't get it, you should have a backup to request it
from the cache.
Because you might expect to need your backup, and because you need data to
be FIFO, you will need either a monatomically increasing index, or a list
of serialized int frames in cache.
To use monatomically increasing index, use:
cache = MemcacheServiceFactory.getMemcacheService("clientBnamespace");
Long index = cache.increment("fromClientA", 1,0L);
This acts as a shared long value you can safely increment across all
instances.
Use this to timestamp your packet of ints.
cache.put("fromClientA"+index, "1,2,3,4,5", Expiration.byDeltaMillis(5000));
Note that this will always be deleted within 5 seconds, so no cleanup is on
you. You may want to give it 30 seconds or more.
Just make sure you send the index value with the packets, so if clientB has
to manually ask, it can do cache get on "fromClientA"+lastReceivedIndex++
until no values are found.
This, of course, could easily drop some of your packets, so maybe not the
best solution...
The other option is to have a list of ints in a single memcache location.
So long as you stick to low-level memcache, you can do stuff like
.putIfUntouched() so you can catch the error to read in updates from other
threads before adding to the list.
If .putIfUntouched fails, you need to do a fresh get(), add in the new
changes, and try again.
Just remember, the order that gets are processed does not necessarily equal
the order that puts are finished.
This is where your monatomically incremented long int comes in very handy.
If you can *gaurantee* that client A won't send more data until it's
previous send has finished, you don't have to worry.
If client A fires off data as soon as it gets it, you will need to
timestamp / orderstamp your packets.
Storing a list of packets {with each packet object having a list of ints
and a long order stamp} in memcache will make for easier, safer reads by
clientB.
Just remember that memcache serializes/deserializes lists you put into it,
so the list you get is NOT backed by the memcache value; you have to commit
a successful put before other threads will see your changes.
Don't use DS writes and reads if you don't have to. Short-lived memcache
operations have all of the features you want at the lowest price on
appengine.
You may want a ds fallback if
(!CapabilitiesServiceFactory.getCapabilitiesService().getStatus(Capability.MEMCACHE).getStatus().equals(CapabilityStatus.ENABLED))
To easily implement a fallback in java, write your .put(), .get(),
.delete() methods in an interface. Have one implementation use only
memcache, and have another that uses ds+memcache or just ds.
If the capability service says memcache is having trouble, use the ds
backed impl.
So long as your FIFO code uses this interface, you can send it whatever
impl you want.
Anyway, if you give me more details about the levels of control you have
over client A and client B, I can likely help you distill a more specific
implementation from the preceding rant.
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-appengine/-/022p_RmsToAJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
