Made the initial CVS import of Grafolia to the Apache DB Project commons-sandbox this Saturday night (what an exciting night!). Grafolia is designed to be a general-purpose unit of work library for Java object graphs. Its specific need is in OJB, however it's not dependent on anything aside from Java 1.2. I hope to see it be useful to other tools which need to manage transactional object graphs.
When I posted the first proof of concept ideas I was asked why it doesn't implement JTA callbacks in order to be managed as a resource. It still doesn't, and I don't think it will. The reason here is that this library will, probably, typically be used on top of another tool which provides the object graphs, and manages transactions. Right now I am focusing on OJB, but once that is solid I want to use an XML:DB backend. The resource which it manages object graphs for should be the JTA resource, I think.
An argument can be made to provide the hooks and making it a first-class transaction system, but it isn't -- it simply does state, state management, graph analysis, attach/detach, flushing, and rollbacks for other transactional systems which want to provide Java object projections. Keep it simple =)
The code should probably be considered fairly fluid at the moment as I am working on optimizing it. Right now it works refelctively, with easy hooks for non-reflective state tracking. The flushing algorithm is designed around the reflective system though -- and I want to find a more optimal solution when fully instrumented graphs are being managed. Right now instrumenting will definately give a performance boost, but the algorithms usable when *everything* is instrumented are different then when some of the graph is instrumented, or none. Finding a good way to mix this to optimize it for whatever situation it finds itself in will be fun.
Oh yeah, no XML =) If you want to change default behavior I took a point from Rod and designed it to be easy to make small component changes for a specific environment rather than try to guess every variation and make the right knobs available in configuration.
0 writebacks [/src/java] permanent link
I spent a chunk of time on Saturday cleaning up grafolia (and importing into ASF CVS) and plunking in the hooks between it and OJB to let grafolia manage OJB's object states. It works really nicely. One of the big goals (personally) for me was to support statement reordering in a robust way. This has been fun =)
Topological sorting is fun =) I haven't been exposed to this particular problem before (though it smells like other directed graph problems), so am trying to come up with a not-too-inefficient algorithm on my own, before I go research the best fit i can find for my class of problem.
If you want to try, a basic comparator function might look like:
public static class TopologicalComparator
{
public static final int BEFORE = -1;
public static final int AFTER = 1;
public static final int EQUAL = 0;
public static final int NO_COMPARISON = Integer.MAX_VALUE;
public int compare(final Change changeOne, final Change changeTwo) {
/* ... */
}
}
That said, the comparator function is probably the wrong apporach and building a directed graph of dependencies and traversing naively will probably yield an easier-to-follow (maintain) algorithm. Wheee, fun fun.