Toplink Persistence Aspects

Posted on March 21, 2005


The next industry track session on Thursday was Object Persistence Aspects by Jim Clark of the Oracle TopLink team. Their first use of aspects was to policy proper application development, notably ensuring that developers didn’t modify objects in the shared read-only cache.

They next developed a way to generate AspectJ aspects from their XML mapping files to support lazy loading and also to replace snapshot-based differences with active dirty tracking while operating on persistent objects for "read mostly" applications.

They subsequently built a custom weaver/bytecode instrumentation engine using BCEL to implement this requirement since it could understand their XML (not require a separate step in the build process), and because they optimized the performance significantly compared to the memory and time required for general-purpose AspectJ weaving. I think this is an interesting case of thinking in aspects being a benefit: at least they could prototype the right implementation quickly, even though they ended up hand-tuning an optimization.

They still require a build-time option for deployment to "non-managed" environments (e.g., 2-tier deployments for testing or unusual app servers) where they can’t weave at load time.

They are interested in leveraging general-purpose AOP in future, rather than maintaining their own, and see opportunities to provide higher level aspects like session management, query prefetching, and transaction demarcation. The initial feedback has been positive to the new "aspect-based" persistence option. They see aspects as the right answer, and preferably provided by the creator of a persistence framework.