His example has gotten me thinking that there may be a way to achieve this with a modified version of what he wrote, but really the bigger point I was trying to make is that many POJO’s shouldn’t be persisted to the db, but only represent some intermediate state and only require some intermediate storage, and Terracotta is a good fit there because Terracotta does not impose any constraints on the API of those POJO’s. Just look at how cluttered the code is in the example you linked to, with all those annotations. That may be acceptable if those classes represent entities that *belong* in the SOR, which they probably do. But it may be worthwhile to free other code from ORM library constraints, if you can just transparently plug Terracotta in at the jvm level and let it handle intermediate persistence for you (not to mention transparent clustering as well).

http://www.theresearchkitchen.com/blog/archives/57

I’m intrigued by your description of Terracotta though and will check it out.