Play framework is stateless, but it natively provides a cache mechanism that let us store some data at server-side. I'm wondering if it's nice to store user's profile there, once play's docs say we cannot trust it that much even when there's no timeout defined, but it looks prettier than always querying my ldap db in order to get logged user profile. Then I made a method called getOrUpdateProfile, that tries to get it from Cache first, if it's gone, then I query ldap and save it again.
Is that the right use? Do you guys prefer cache or session? Thanks
Since Play's session is just an ordinary cookie it is completely exposed to client side. There are cases where you want to keep some data transparently to users, especially if this data is vulnerable.
The use case that you described is absolutely correct. Using a cache mechanism can definitely improve performance. You only need to be aware of two things when working with a cache layer.
Firstly, remember that data in a cache is volatile so always be prepared for a situation where it has no data that you look for. Don't rely on a cache. Use it as an addition to a main data flow which provides a performance boost. Always persist changes of data to a non-volatile storage.
Secondly, by turning on a cache you lose default stateless nature of Play applications. This change is significant when clustering is one of system requirements. You need to make sure that cache coherence is maintained across all nodes.