So up to this point, been storing player XP in a custom runtime collection along with a slew of other player related fields.

Any particular reason why I should (or should not) switch to using one of the 6 currencies or even a virtual good to track XP - other than the convenience functions allowing easy credit/debit/balance/hasVGood/useVGood?  

Near as I can tell, the values are simply stored in the system Player collection (much as my current XP is stored in my custom runtime collection).

Thanks in advance!

bump

Thanks for the reply - follow-up - I assume the atomicity is obtained by virtue of using mongodb $inc or some such mechanism - but one of the issues I came across was the 'zero balance' concept.  Player has 18 of a particular currency or virtual goods count - I want to debit 20, and if they don't have enough, make it zero.  While I can simply detect if the debit/useVGood fails (for lack of available balance), and then debit the current balance (by reading the balance first).  In such a multi-step process, concurrency rears its ugly head and another process could easily have jumped in and changed the balance and I end up with screwy results.  The issue is not solved by using my own custom collection - as I have to essentially execute the same number of steps.  I don't know if the issue is solved by built-in mongodb optimistic locking - but I doubt it.  Any thoughts?  Can/should I use a mutex-type lock with lockKey() (maybe with a key value of player id or a hash of player and currency type) to block others from accessing until group of activities are complete - thereby creating a transaction (or at least a sense of atomicity)?  Thanks in advance!!