On 28/02/12 11:03 AM, Norbert Hartl wrote:

I first used image persistence but the image grow to large. Then I added
fuel as journal to be written before image save in order to be able to
recover from an emergency.
Now we redo the persistence part. An account object graph is dissected
into configuration part and payload part. The payload is written
directly to mongo db in a Json format. The configuration part will be
written as fuel blob to mongo. Planned is that at startup a configured
amount of account fuel blobs are loaded and started. Those

configurations have their own proces ses that write back payload to
mongo. Etc.

That's similar to what I do, except no image save and no mongo db.

Here's how it goes:
- on restart the image reconstructs a Pier kernel saved via Fuel to a file
- included in the Pier kernel is what you're calling the "configuration part" - there are custom (non-std Pier) components here.
- the components in the reconstructed image can read/write a "payload" part, which is serialized to files using Fuel and SandstoneDb.

- additionally, a "sub-tree" of the Pier kernel can be exported to a file using Fuel serialization, and later imported using Fuel deserialization.

No URL available at the moment.

Aside - before Fuel/SandstoneDb, I was using Glorp/PostgreSQL. I've gained a lot of simplicity, but lost sequence numbers

and object caching (and maybe more things, that have not been a problem so far). I've written a seqno replacement, but the lack of object caching is not a problem at the moment (i.e. small data sets, so far).