POJO Mojo

i saw jonas's talk today. i had never considered using the spring application context to store data objects. typically the apps i have seen have the (stateless) business objects in spring.

i stopped by the pavilion booth and talked to someone named eugene; when i asked in what circumstances one would be putting data in spring, eugene told me that terracotta "doesn't do consulting", which i took to mean that i'd have to figure this one out myself. funny, i thought if you wanted me to use your product y'all could tell me why i'd want to...

Hi John. I think Eugene was just describing our business model, which is license-based rather than service-based. But of course it's critical for us to do everything we can to help our customers be successful.

If you'd like, please contact me by email directly (pcal at terracottatech dot com) or stop by the booth again tomorrow - I'd love to chat with you more about your use case.

John, I only pointed out that Terracotta does not provide tranning for the Spring framework itself and was suggesting to use some imagination. It is really hard to suggest what you can store to Spring context without analyzing your application. In general, there are plenty use cases when beans in Spring context may have state. For example, caching results from expensieve operations (including access to the database), collecting data about your system, interprocess coordination, queuing task execution and so on and so forth. In Spring 2.0 you can also used scoped beans where bean will have unique state within given scope, such as request, session or even custom scopes.