0

I am working on a web service servlet running on Google App Engine using Spring 3.1, and since I'm pretty new to this game, I simply don't know how I should be caching things. It seems like there are a number of places I can put things to be maintained during the lifetime of my servlet:

  1. Application context. Defining beans here would allow me to easily inject them into my code. This seems like the easiest solution, just scope my beans to be singletons.
  2. Servlet context. For this, when my servlet starts up, I can put things in the ServletContext by grabbing the instance of it, and doing a setAttribute().
  3. Memcache. I haven't looked into this much yet, but I imagine I would just get an instance of the cache, and shove an object into it like the ServletContext.

The specific case I'm curious about is for creating user accounts. I want to keep a HashSet of all user IDs so that I can check if the requested user ID is already in use.

Beyond the specific case above, including cases for using each of the different technologies would be appreciated.

Improve this question
2
  • Note that 1 and 2 are effectively the same. In the average servlet based MVC framework, the "application context" uses under the covers the servlet context attributes. It's just one extra abstract layer. Commented Jun 20, 2012 at 17:59
  • I don't think storing all user IDs in a HashMap cache is a good idea. First, this won't scale horizontally. Secondly, you need to synchronize reads/writes from/to it in order to make sure there is no race condition. Commented Jun 20, 2012 at 18:02

1 Answer 1

Reset to default
2

In your specific case I recommend you to use a persistent storage, like the datastore or cloud sql (you can see all alternatives here).

Memcache is not an option, since you can't control how many elements are stored. And any application context is not a solution either, since the instances are in practice being loaded and reloaded many times in different datacenters.

Note also that AppEngine provides support for using Google Accounts or OpenId via the Users Service.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Good points. To be clear, every time I need to check if a user ID is used, I'm hitting the datastore? Can you give examples of when I would use memcache/application context/servlet context
Yes, you would be hitting the datastore every time, but you can index that property. Typically you use memcache for caching slow/expensive queries/processes, for example retrieving the whole profile of a given user (which could involve computing usage statistics, etc). The common pattern is: if element(query/process/etc) in memcache return it; otherwise compute it, save it and return it; and also you need to be aware that whenever you change a resource that could impact the previous result you need to invalidate that entry in the cache.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.