Another idea to speed up synchronization on a high concurrency transactional level, would be to create a single java backend instance that takes in tasks from the front ends and process it in a singular queue. That way you know the time is just from one server and you also know its from a single threaded queue.
On Thursday, July 25, 2013, Evan Ruff wrote: > Hey guys, > > Thanks a lot for the interesting ideas about handling this issue. So for > in my application, I need to be very sensitive (mils) about the arrival > time of requests to resolve conflicts in data assignment. > > Basically, I'm worried about two requests coming in around the same time, > hitting two different instances, then having to resolve which request was > "first". > > I've thought about creating a memcache-based semaphore based around the > actual data ID that will be assigned, but I thought I'd see if there was a > slicker way that anyone had used. > > Thanks, > > E > On Jul 25, 2013 4:07 PM, "alex" <[email protected] <javascript:_e({}, > 'cvml', '[email protected]');>> wrote: > >> Evan, if the question here is whether currentTimeMils() returns correct >> time, it's all managed for you, obviously including correct time. This is >> not an EC2 instance. >> >> Not that it probably matters here but Google introduced a concept called >> "true time", which IMO even more accurate than NTP in some sense. I don't >> know if servers that run appspot apps use it at some level, but I know for >> sure Google team use it in Spanner. >> >> Anyway, why would you want to adjust current system time, do you have >> evidence that it's not accurate enough? >> >> On Thursday, July 25, 2013 6:53:34 PM UTC+2, Evan Ruff wrote: >>> >>> Hey guys, >>> >>> I'm curious to hear about any strategies people have used to employ time >>> synchronization among the AppEngine instances. I'm working on a project >>> that is looking to have a pretty important time component and the current >>> strategy I'm looking at is something long the lines of: >>> >>> 1. Record System.currentTimeMils() >>> 2. URLFetch to an NTP server somewhere >>> 3. Note return time >>> 4. Correct NTP time using the start time to get request time. >>> >>> Is this how other people are handling it? Is there another way that >>> might be simpler? I'm a little hesitant to run an URLFetch for each >>> request, obviously. >>> >>> Thanks! >>> >>> E >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Google App Engine" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/google-appengine/PPbVax3k1s0/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> [email protected] <javascript:_e({}, 'cvml', >> 'google-appengine%[email protected]');>. >> To post to this group, send email to >> [email protected]<javascript:_e({}, 'cvml', >> '[email protected]');> >> . >> Visit this group at http://groups.google.com/group/google-appengine. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:_e({}, > 'cvml', 'google-appengine%[email protected]');>. > To post to this group, send email to > [email protected]<javascript:_e({}, 'cvml', > '[email protected]');> > . > Visit this group at http://groups.google.com/group/google-appengine. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
