> For a number of possible reasons (including the consistency of a > running balance), an accounts engine might have a basic specification > requirement that invoices are generated in sequence with ascending > invoice numbers *and* ascending invoice time/date.
Except that consistency doesn't require both. Either one is sufficient and trying to have both merely puts you in the situation of a person with two clocks - you don't know which one is correct. Moreover, it's easy enough to fake an ascending time/date. (Take the max of the system time and epsilon past the most recent entry.) If time is actually an issue, you can't use system time unless it's guaranteed to be accurate, not just consistent. For that, you're probably better off consulting an accurate time source. On Dec 27 2008, 12:58 pm, rvjcallanan <vinc...@callanan.ie> wrote: > > How could these users know that the application used inconsistent > > timestamps? Even if they knew of each other's existence, which they > > don't, they don't have synchronized clocks. > > It is not necessarily about users knowing anything! > For a number of possible reasons (including the consistency of a > running balance), an accounts engine might have a basic specification > requirement that invoices are generated in sequence with ascending > invoice numbers *and* ascending invoice time/date. Given that many > users may be generating purchases "simultaneously", this suggests a > requirement for a centralised universal reference clock used > specifically for invoice creation. > > > The case where it's easiest for a user to detect the consequences of > > clock skew is a burst of requests from single user. However, as long > > as your client doesn't send simultaneous requests, all requests by a > > given user within a short time frame are likely to be served in order > > by the same process and that process is self-consistent. > > "Likely to be served in order by the same process" just ain't good > enough! > > I realise it is early days yet and I repeat my earlier clarification > that I am not a GAE party pooper! Simply hoping that the kind of > scenarios I mentioned are given due attention by GAE developers in the > (near) future. > > Rgds, > rvjcallanan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. 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 -~----------~----~----~----~------~----~------~--~---
