This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Prevayler Problem in Smalltalk
Feed Title: Michael Lucas-Smith
Feed URL: http://www.michaellucassmith.com/site.atom
Feed Description: Smalltalk and my misinterpretations of life
Janko Mivsek is an inspiring guy sometimes. He's had this idea that the "prevayler" concept - an in memory database of objects that can be recovered off disk when an image starts up - can be done a lot better in Smalltalk.
The goals are roughly like this: Don't even impose on the developer. This is the sort of philosophy that's made Avi famous for Seaside. Let the developer write code and have mechanisms around/behind it that handle the tricky stuff.
In this case, we're effectively trying to turn the objects in an image in to an OO database. Query-ably, recoverable, perhaps even ACID. Who knows, the sky is the limit - perhaps more than one image can access and update this information at the same time.
These are all interesting goals, so we set out to prototype some of this stuff. The package is called Prevayler and it's in the Public Store. The original prevayler idea is a Java one and it is a mass of API's - like most Java things. There is a Smalltalk version of it for Squeak and I think it was even ported to VisualWorks at one stage. But we wanted to get away from the API idea.
So in our prevayler, any and every object is persistable. This is done by re-using BOSS as a binary object store for all the objects. This takes all the work of persisting data to disk away from me, the implementor.
The next trick is knowing when something is changed. In Smalltalk you can mark any object you want as being immutable. Any change to the object will result in an exception. So we can set our desired objects to be immutable and catch the exception on them to know when they are changing.
Because exceptions are resumable in Smalltalk, we can also resume the exception once we've done our duty. That's the crux of the system. Throw in some proxy's and you're pretty much there.
That much we got working in under 30 minutes over IRC. But the problem of garbage collection came up. The idea is that if any object gets GC'd in an image, some piece of code made that happen, and therefore a developer wanted it to get wiped. Another image looking at the same data source should check to see if the disk version of the object still exists when attempting to reuse t across images.
This took under 30 minutes to implement too - except that I was seeing lots of messages about garbage collection in the transcript that I wasn't expecting. I left it at that and went on my holiday.
Now that I'm back I've realised what was happening. As I was stopping and starting the system, I was seeing the GC's of the old objects. The problem is - they have the same ID's as the new objects, especially the root dictionary object which has an id of 0. Wipe it and you lose all your objects.
So.. question.. if someone wants to get rid of the existing prevayler instance in their image - how do I allow them to do that without suddenly wiping all the objects off disk?
Previous Topic
