[Objectbridge-developers] Re: [objectbridge - Open Discussion] RE: Cache Manager & RSIterator

[David Dixon-P. <dp...@mi...>]

Thomas,

If the Objects are maintaining Identity, then perhaps we should say that
explicitely in the code.

Lets create a class "Identity" which basically maintains:
    Class Name
    Primary Key values for an object

This class would have the following methods:
    getObject( boolean forWrite )
     releaseObject()

getObject will lazily load the entire object into memory, as well as handle
things such as locking.  This handles two problems at once:

As long as getObject() and releaseObject() are called consistently we
can manage the locks,  and guarantee such useful stuff as Read Consistency.

This would also act as your proxy in doing lazy evaluation.

The other thing this allows us, is to move the Object Building code out of
RsIterator and the PersistenceBroker, and only concentrate on making
Identities out of result sets.

Let me know what you think,

David.




no...@so... wrote:

> Read and respond to this message at:
> http://sourceforge.net/forum/message.php?msg_id=72106
> By: thma
>
> Hi David,
>
> You are right this is a bit ugly.
> One of my design goal was to maintain object identity (i.e. if two objects have
> the same PK values
> they are one and the same instance).
> When you are looking up a single object by its PK values this is simple: lookup
> the ObjectCaches
> hashtable and only load from db if nessesary.
> If you select multiple object with a multi-row resultset it's a bit more difficult.
> because each row does
> eventually represent an object that is already cached.
> To resolve these potential conflicts I chose a slow solution: build an object
> from the resultsets row,
> take the Objects pk field Vector to make a standard lookup using the persistence
> broker etc.
> If an Object is already cached the first loaded object is dicarded and the cached
> Version returned ==> allocation overhead
> If an Object is not yet cached the ObjectCache performs a second db Lookup,
> and the first object is discarded agein ==>
> even more overhead through double lookup.
>
> If it was this simple we might build a quick workaround but:
> The first loading by RsIterator does only fill the skalar fields of the object,
> whereas PersistenceBroker::getObjectByPk
> does a bit more, if loading is necessary it calls getDBObject which loads also
> References an Collections.
>
> of course you can copy all this logic right into RsIterator::getObjectFromResultSet
> but I don't like this kind of code doubling.
>
> three other approaches:
> 1. in RsIterator::getObjectFromResultSet don't fill all the objects skalar fields
> but only the pk values of the temporary
> object obj. This wil reduce Reflection overhead.
> 2. invent new methods in PersistenBroker which take the stubbed object obj as
> a additional parameter
> and try to fill it's reference and collection fields in order to reduce lookup
> overhead.
> 3. I'm dreaming of a proxy concept for the management of reference and collections.
> Such a concept would make direct interaction
> with the ObjectCache much saver. Why? if today an object is cached and any of
> its reference attributes
> has not been loaded the reference == null and the application developer has
> fill the reference attribute by own application code.
> Otherwise he will get null-pointer exceptions.
> If using Proxies the refernce attribute will hold a proxy object which is clever
> enough to do on demand lookup
> when client code accesses the attribute.
> I did not implement any proxy stuff in the PersistenceBroker phase because the
> PB should capable to persist
> arbitrary objects.
> But once we start with a transaction Manager, the client code needs a higher
> integration with the persistency framework
> an then its pretty ok to force the developer to use proxies and interface etc.
>
> --
>
> I set up a mailing list
> http://lists.sourceforge.net/mailman/listinfo/objectbridge-developers
> I think its a good idea to use this medium so everyone can participate in all
> discussion.
>
> regards,
>
> Thomas
>
> ______________________________________________________________________
> You are receiving this email because you elected to monitor this forum.
> To stop monitoring this forum, login to SourceForge and visit:
> http://sourceforge.net/forum/monitor.php?forum_id=43066