Little says, add transactions and forget about throughput. Also, if you go rely on memory only, you need redundancy. In fact, for these types of systems, you always need redundancy. POS terminals won't be safe as they will lack redundancy.
Regards, Kirk On 2012-01-09, at 1:15 AM, Kevin Wright wrote: > I'd be tempted to argue the exact opposite. With something like the lottery, > you want to be pretty certain that you absolutely have a record of every > single ticket purchase. If a machine should suffer a fault and lose ticket > purchase information that happens to contain a future winning ticket... > > Run *everything* in duplicate, triplicate or better. Use a tool like VoltDB > and hardware that can handle persistance at that speed, ensure that records > are kept in EPOS terminals, it's also essential that some form of > non-forgeable receipt is issued as well. > > Because you don't want a £23 Million winning ticket to either be lost in the > system, or faked. Allow for online sales and assume that people will try and > hack the EPOS terminals as well, so everything wants to be mediated via some > form of centrally controlled authentication. > > In other scenarios, you can work with eventual consistency and trust remote > machines a lot more (especially if they're 100% under your control), so > batching makes a lot more sense. The lottery has a number of unique > characteristics, which means that it's unlikely to be a good example how how > to design things for other use cases. > > > On 6 January 2012 15:19, Kirk Pepperdine <[email protected]> wrote: > very easy.. with lottery tickets you need only record what has been picked… > those results can be aggregated locally and then aggregated in batch. Since > there is a limited number of choices, typical less than 100 million, you can > easily store all of this in memory. I'd compute an index into a cyclic group > that represents all possible lottery choices. so recording a simple counter > bump. For that you can use a concurrent counter. You can add the index to the > vendor if you need to track that.. in a similar concurrent data structure. > Again, things can be aggregated later if need be. > > Kind regards, > Kirk > On 2012-01-06, at 4:11 PM, Rakesh wrote: > > > ok, so lets say its a lottery application. > > > > That means in the run up to the big draw on Saturday night its likely > > to get insanely busy! > > > > I can't see a way around not needing transactions but if there is a > > way, please elaborate. > > > > R > > > > On 6 January 2012 14:19, Kirk Pepperdine <[email protected]> wrote: > >> I think all the points are good.. they just lack context.. and so not all > >> of > >> them are going to fit.. > >> > >> Kirk > >> > >> On 2012-01-06, at 3:18 PM, Robert Casto wrote: > >> > >> All these technology ideas are great but what is the task that all these > >> people will be doing in such a short time frame? > >> > >> Can you avoid some work during this time period? Batch it up for later, put > >> it in a queue, or have a process come by later and do cleanup when the > >> systems are less busy. Do as little as possible while accomplishing just > >> what is needed during this time. Doing less means you can get more done in > >> the same time period without having to add more machines or make drastic > >> changes. > >> > >> On Fri, Jan 6, 2012 at 9:10 AM, Fabrizio Giudici > >> <[email protected]> wrote: > >>> > >>> On Fri, 06 Jan 2012 15:03:59 +0100, Kirk Pepperdine > >>> <[email protected]> wrote: > >>> > >>>> All nice points. > >>>> > >>>> I would add.. avoid transactions like the plague. > >>>> Single threaded will be easier to scale out.. (think http) > >>>> +1 on keep things in memory.. in fact I've customers that no longer put > >>>> disks in their machines.. which surprisingly increases reliability.. > >>>> (which > >>>> really shouldn't be surprising). > >>> > >>> > >>> +1 on everything, including the last point, but you can have a hard time > >>> to persuade customers acquainted to the database for decades. It's > >>> possible > >>> to use a hybrid approach: for instance Coherence (but AFAIK other similar > >>> products) has got a "write behind" mode in which you basically commit to > >>> memory, and then an async task pushes stuff to the database. I'm trying to > >>> persuade a customer to go that way, but I still see raised eyebrows. But > >>> perhaps we'll be able to start some serious prototyping in the next > >>> months. > >>> > >>> > >>> -- > >>> Fabrizio Giudici - Java Architect, Project Manager > >>> Tidalwave s.a.s. - "We make Java work. Everywhere." > >>> [email protected] > >>> http://tidalwave.it - http://fabriziogiudici.it > >>> > >>> > >>> -- > >>> You received this message because you are subscribed to the Google Groups > >>> "The Java Posse" group. > >>> To post to this group, send email to [email protected]. > >>> To unsubscribe from this group, send email to > >>> [email protected]. > >>> For more options, visit this group at > >>> http://groups.google.com/group/javaposse?hl=en. > >>> > >> > >> > >> > >> -- > >> Robert Casto > >> www.robertcasto.com > >> www.sellerstoolbox.com > >> > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "The Java Posse" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> For more options, visit this group at > >> http://groups.google.com/group/javaposse?hl=en. > >> > >> > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "The Java Posse" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> For more options, visit this group at > >> http://groups.google.com/group/javaposse?hl=en. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "The Java Posse" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/javaposse?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > > > > -- > Kevin Wright > mail: [email protected] > gtalk / msn : [email protected] > quora: http://www.quora.com/Kevin-Wright > google+: http://gplus.to/thecoda > twitter: @thecoda > vibe / skype: kev.lee.wright > steam: kev_lee_wright > > "My point today is that, if we wish to count lines of code, we should not > regard them as "lines produced" but as "lines spent": the current > conventional wisdom is so foolish as to book that count on the wrong side of > the ledger" ~ Dijkstra > > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
