[Objectbridge-developers] Cache Manager & RSIterator

[Thomas M. <tho...@ho...>]

>                By: dpeugh ( David Dixon-Peugh ) 
>                  Cache Manager & RSIterator [ reply ]   
>                2000-Nov-03 17:08 
>                Your Cache Manager implementation is very slick. I've been thinking 
>                about how to implement this type of caching in Java, and all I can 
>                say is you've got the right thing going here. 
> 
>                I found something in RSIterator.getObjectFromResultSet( ... ) that is a little 
>                confusing. Here is how I see the logic. 
>                New instance of the class is created. 
>                This instance gets its fields populated from the data values in the ResultSet 
>                The Primary Key fields are passed from the Instance to the PersistanceBroker 
> 
>                PersistanceBroker looks in the cache, and if it doesn't find one, goes to the 
>                database to pick up a new object. 
> 
>                What I'm wondering though, is why the instance that gets created from the 
>                ResultSet is discarded if it isn't in the cache. Is there someway of saving us 
>                from the extra database call to rebuild an object which should be there? 
> 
>                Or are we intentionally just writing queries which return the Primary Key. (If 
>                so, we can reduce the amount of reflections in executing a query.) 
> 
>                Thanks, 
> 
>                David. 
> 
> 
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