Link Details

Very interesting read, it does seem like we could save an awful lot of work by removing the whole RDBMS/ORM layer.
Indeed it would be nice if there were a C# compiler for Java out there, if so I would be using LINQ to mitigate the RDBMS vs. OO impedance mismatch rather than typing ugly type-unsafe JPQL stuff in annotations, or worse, XML-files.

Ammmmmm... what about shared state? (ie. I save some data, and another user read it).
,Ammmmmm... what about shared state? (ie. I save some data, and another user read it).

Actually, shared state is what most of the post is about. TC basically allows sharing the objects among multiple machines. Though not completely accurate, imagine treating a cluster of machines as if it was one multi-proc system with one heap.

I have been thinking about data warehouses for a while. RDBMS do not seem to actually be the best choice for them. For instance - http://www.dmreview.com/issues/2007_42/10000432-1.html

Alex Miller wrote a blog post a while ago about data lifetimes and where the sweet spot is for Terracotta shared state: http://tech.puredanger.com/2008/08/01/thinking-about-data-lifetimes/

In short, the database is still useful for long-lived data storage as a system or record. However, by putting short and medium terms data in memory with or without Terracotta, you're not trouble by the performance impact of the database as much. You can for instance asynchronously write back to the database in the background.

I just wonder though, I've looked at using Terracotta as a semi-in-memory-database, but if you try to query a large collection, how fast can you query it to find what you need? Would it be as fast as querying an RDBMS?
,

How can you index your collection in memory so it will be just as fast?

I would expect anything in-memory to faster than disk access. Combine with the elimination of creating a prepared statement, the DB to parse the SQL, JDBC driver overhead, and elimination of the cycles to assemble the objects from the RDBMS result set......