Here's one approach.
On authentication, a mobile receives a random security token which is stored against the user in the database, but also stored in an in-memory cache (shared by all servers) mapping a user id to a token.
Every time a mobile user communicates, it includes the user id and security token which is checked against the cache: if the token does not match the token in the cache, then the database is checked. If the token does not match the token in the database, the communication is rejected with a message indicating the user is not logged in on this device or logged in elsewhere, with the option of re-authenticating.
If a user explicitly logs out, the security token can be set to a special value in the database indicating the user is not logged in, and the entry removed from cache.
Size of in-memory cache is of the order of (number of users logged in) * (user id + security token length + overhead) * 2. For 10,000 users, GUID used for user id and security token, gives approximately 10,000 * (16 + 16 + 8) * 2 = 800 kBytes. So size of cache is not problematic. Use hash-with-chaining to allow deletion of hash entries, or look at the many open source key value stores out there.
It the "sessions" table containing the user and session token is small enough, the database may do a good job of caching the table it itself, in which case the sessions cache and extra logic may not be needed.
If you have an estimate for the frequency of communication between the mobile and the server, consider running an experiment to see if the cache is needed.