The records are only cached within a single transaction (this is the default behavior). I still see the problem with transaction demarcation: since you don't wrap every request (including these which only read from database), your SELECTs "see" the results of a single transaction (which spans from first request). Please consider the filter for transaction-per-request we were talking about earlier.
As for the caches, you do not need to invalidate them manually as long as you use `save`, `INSERT`, `UPDATE` or `DELETE` methods (ActiveRecord-style persistence). You only need to maintain the cache manually if one of the following conditions are met:
1. There are auxiliary database objects (triggers) that change the data -- and you wish to see the changes in the same transaction.
2. You use custom DML query -- and you wish to see the changes in the same transaction.
3. The data is modified externally -- and you wish to see the changes in the same transaction.
4. You use application-wide cache (e.g. Ehcache) and one of the above conditions are met.
You see, our ORM is all about transactions :) When you are working on a strongly concurrent application (such as any web application), the transaction-per-request seems like the only choice. I am sorry that our documentation is very sparse about transactions, I think I can manage to completely rewrite it some day.
As for now, feel free to post your questions there, in the group.