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.

Reply via email to