A while back I remember writing a Prevayler like client that did transparent object persistence using BOSS files on disk. I was pretty pleased with the technique I used. Basically, I would mark objects as immutable and when the immutability error was fired, I had an override that would run and record the change to disk and allow the change to proceed.
This wasn't exactly a new idea - Gemstone does it, my code does it, a few other programs I know of did it. The problem was, they would all override the same immutability methods - which meant that loading one of these libraries meant you couldn't load one of the others.
Back around VisualWorks 7.3 time, some Gemstone guys and Eliot Miranda worked on a framework called ModificationManagement - you can load this in the preview parcels that come with Cincom Smalltalk under the directory preview/modtracking. The basic premise of this package was to allow applications to share the immutability engine.
There were problems with the framework, naturally, it gets very confusing as to the correct behavior of more than one immutability policy wants to apply to the same object. Who takes precedence? Those sorts of questions are pretty much unsolveable at the framework level, but completely solveable at the policy level (the level where the person using the framework lives).
The thing that made ModificationManagement stay in preview though was the way it handled registration of objects. It had this ingenious technique of creating weak identity dictionaries for each policy so that the policy could know what it had registered. This caused three major problems:
- This imposed the main technique used to monitor what object is handled by who
- If you have more than one weak array for the same object, it won't get garbage collection - you must use ephemerons instead which take up more memory
- Existing immutables - symbols - of which there are lots, are put in to a redundant second dictionary for the immutability policy
So Myself, Alan, Martin and Tamara sat down (well, Tamara was on the other end of skype, but I assume she was sitting) and looked critically at this framework. It had become apparent to us that we wanted to use it with Glorp to do automatic "unit of work" registration for existing objects. We decided to take the basic concept and see how simple a framework we could implement for it.
The resulting framework is called Write-Barriers and will be in preview for VisualWorks 7.6. It's available already in the public repository.
The framework differs from ModificationManagement in its light-weighted nature. It does not provide a mechanism for keeping track of which objects you are managing - instead it leaves that implementation up to you. For example, if you wanted to track symbols, you could go and see if the object in question is interned in the symbol table instead of holding on to a collection yourself.
Another difference is that any object that is marked immutable without using a WriteBarriers.Tracker is off limits to Write-Barriers. That means all existing literals and immutables in the image won't be touched by WriteBarriers, reducing the complexity and overhead even further and avoiding the redundant policy for immutable objects in general.
To use Write-Barriers, you make a subclass of WriteBarriers.Tracker and implement a couple of methods:
- isTracking: anObject -- answer true if our tracker is tracking the object
- privateTrack: anObject -- register and remember the object in whatever fashion you want
- privateUntrack: anObject -- forget about the object you were tracking
- applyModificationTo: anObject selector: selector index: index value: value -- We've accepted that we are tracking the object and a change has been made to it, what do we want to do? The default behavior is to apply the change to the object.
At this point you can start to make some interesting behavior with trackers, such as an object-change logger. In #applyModificationTo:selector:index:value: you can record to a log the kind of change that has been visited upon you. Or if you're a persistence framework such as Glorp, register the object in the unit of work.
The latest version of Glorp is capable of using Write-Barriers if you tell it to and will be shipping with VisualWorks 7.6 and the next version of ObjectStudio 8. It'll also be part of Web Velocity. The upshot is, if you're using UnitOfWork in process with WriteBarriers, you don't have to manage the unit of work object yourself, just commit the main object you're focused on and any other ancillery objects that already existed that have been changed will also be in the unit of work.
I hope that for VisualWorks 7.7, we'll be able to merge Write-Barriers in to the base, so that the overrides disappear and this becomes the general mechanism for applying a "write barrier" to an object. (Kudos to Alan for picking the name)