The Artima Developer Community
Sponsored Link

Legacy Java Answers Forum
October 2001



This page contains an archived post to the Java Answers Forum made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.


Object Persistence(Materialization and Dematerialization)

Posted by Kai on October 09, 2001 at 1:54 AM

I've encountered some issues with mapping my objects to an RDBMS and am hoping for some advice.

I've tried various O/R mapping frameworks like Castor(too complex and too slow for my liking), JRF(nice but very repetitive and difficult to extend) and then some, but have yet to find one which I'm comfortable with building an application on.

Instead, I've chosen to do it the low-tech way, with each domain class, say Book for instance, having a Broker class which knows how to communicate with the chosen form of persistence. So, since I chose an RDBMS, Book class has a BookRelationalBroker class which knows how to materialize and dematerialize Book objects to and from a RDBMS. If so required, I can plug in a BookXMLBroker which knows how to serialize the object in the form of an xml data file.

I've also implemented a primitive object caching system which (when enabled), caches objects requested so we only have to materialize it from the db once.

Here are 2 issues I have with my system:

  1. It is amazingly tedious (not to mention inefficient) to recreate the entire object from the database. This is even more so because I've implemented the Event Notification pattern, such that when say a book is deleted, the members who have reserved it are notified. The whole point of the Event Notification mechanism is so that the object being watched does not need to know of the objects which need to be notified on a state change. However, I've found it necessary to re-attach all the listeners on an object when it is materialized from the DB, defeating the purpose of the pattern.
  2. Complex object relationships are mapped poorly and recursive materialization leads to slow response times. If a Group object has a Vector of Members and other Groups, then whenever a Group object is materialized, all its constituent Members and Group objects also need to be materialized. (I understand O/R frameworks solve this through lazy instantiation)

    I studied the Jive2 architecture and found that they approached this problem by accessing the DB directly for any complex object relationships. In other words, the Group object does not actually contain a Vector of Members and Groups. Instead, it has a method called say getMembers() which proceeds to retrieve the necessary data from the DB and then materialize these objects.

    I'm not too excited about this approach for 2 reasons:

    1. How object-oriented is this approach? Seems more like database-oriented programming to me.
    2. Every call to retrieve Members necessitates a call to the DB. The data isn't cached with the Group object because the Group object does not actually contain the necessary reference to the Members and Groups.

Can anyone shed some light on this topic?


Sponsored Links

Copyright © 1996-2009 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us