Cool idea. Forget databases. With massive cheap RAM just keep business objects in RAM and persist snapshots of them once in a while. In-between snapshots, record all incoming commands in a log file. If you crash just, rehydrate the last snapshot, apply commands in the log file and keep running. Read the FAQ for details.
Key issues with the approach:
- Data must never grow larger than memory (massive swap file?)
- No query language for object pool (solvable)
- Impact of object schema changes on production systems
- Possible data inconsistency if exception thrown
- Loss of declarative specifiers for data types and relationships
Benefits:
- ACID all taken care of; no explicit transactions
- Simple technique; less code than O/R mapping approaches
- Very high performance possible
- No database license costs
Many years ago I ran into the idea of putting the transaction semantics above the object layer. That's what this essential does. Not sure how they can claim that rollback is no longer needed. What happens if one object rejects a state change? How do previous objects changed in the same transaction get reverse?
What intrigues me most is how this could dovetail beautifully with code generation. Need to chew on it some more. Seems like a great approach to systems with very complex business logic but not too much data.