This post originated from an RSS feed registered with Java Buzz by Brian McCallister. Original Post: Grafolia Import Feed Title: Waste of Time Feed URL: http://kasparov.skife.org/blog/index.rss Feed Description: A simple waste of time and weblog experiment Latest Java Buzz Posts Latest Java Buzz Posts by Brian McCallister Latest Posts From Waste of Time

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.