Counter persistence - again, depends on the requirements. Message beans would the easiest, but for better scalability I would implement a custom consumer for the queue that would read the queue and write many hits at once as a single DB transaction. Even without partitioning, that “write many at once” method can be tweaked to persist millions of records an hour based on similar personal experience. Primary bottleneck would be bandwidth to the DB or disk IO of the DB. If this becomes the bottleneck, then sure, partition it.

-Pete

Yes, from Manlius.

Second, I’d caution about the message queue. Where are you going to persist those messages? Are you concerned about possibly losing them?

Third, if you are using Java, you want to look at AtomicLong.

Fourth, if you have a group of message beans (man, that’s old school. you haven’t switched to Spring yet? are they going to write to the same counter? If so, you have the same contention issue. Or are you going to use partitioned counters?

First, you need a single counting entity. Static session bean type thing.

When it is created, it loads an initial count from a persistent store and sets in it in a variable.

When it is asked to get/increment count it would (in a synchronized/locking method)
1. Increment the counter variable
2. Throw a (small) “hit” event onto a message queue
3. Return the new value

Problem 1 solved..how to count fast in a synchronized manor.

Problem 2 is left…persisting the data. There are a few options here. The most simple option would to have a group of message beans read the queue and write the records to a DB.

This method should be able to scale very well. For outputting a new “hit” value, no DB read is required.

A fail-over system could be implemented to handle counts for downtime situations with no data loss.

Thanks for giving my brain a simple yet complex problem to crunch on this evening.

Are you the Seth Ladd from Manlius, NY?

Peter Daly