Title: RE: [castor-dev] Castor cache hack

Hi there,

I'm trying to use Castor as the persistence framework and I have encountered the
following problem.

I have an object of class Computer that extends Product.

In the same transaction, I use Castor to retrieve the Product object
and then do it again to retrieve the Computer object. Immediately when
doing the second lookup I got an exception in castor saying that I'm
retrieveing Computer object but the result returned is Product.

For simplicity sake I have trimmed the code a little bit:

        productOql = db.getOQLQuery( "SELECT p FROM myapp.Product p WHERE id = $1" );
        productOql.bind( 6 );
        results = productOql.execute();

if the product type is "COMPUTER" I do the second lookup:

        computerOql = db.getOQLQuery( "SELECT c FROM myapp.Computer c WHERE id = $1" );
        computerOql.bind( 6 );
        results = computerOql.execute();       


The exception that I got is:

org.exolab.castor.jdo.PersistenceException: Requested to load/fetch an object of type myapp.Computer, where persistent storage returned an object of type class myapp.Product

I've been working through the Castor code, it seems to me that Castor stores the object that have been loaded before into the Cache and try to use that object instead the executing a new SQL query.

I have disabled the cache using the hack suggested by Kevin Smith, and althought the cache is effectively disabled, I am still getting the same exception. Is there a cache of loaded object types or something like this? Am I missing something? Is "inherintance 1-N" fully implemented?

TIA,
Alvaro Mart�n
Iberm�tica
(Spain)

-----Mensaje original-----
De: Smith, Kevin [mailto:[EMAIL PROTECTED]]
Enviado el: viernes 8 de marzo de 2002 16:15
Para: [EMAIL PROTECTED]
Asunto: Re: [castor-dev] Castor cache hack


Another option is to edit org.exolab.castor.persist.LRU and change:

DEFAULT_TYPE = CACHE_TIME_LIMITED

to

DEFAULT_TYPE = CACHE_NONE

Then _no_ caching will occur. Not sure about the transactional/performance
implications of that, though. . .
-----Original Message-----
From: Smith, Kevin [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 08, 2002 9:10 AM
To: [EMAIL PROTECTED]
Subject: [castor-dev] Castor cache hack


Based on requests from the cache-types thread, here is a walkthrough of a
temporary hack I implemented to purge the cache for a given Java type. I was
going to include a zip file of the changes, but I'm currently fighting some
VisualAge problems. If people are still interested, I can post the zip file
once I fix my problems.

This hack is purely for investigatory purposes. Please do not use this in a
production or semi-production environment.  It was coded in 45 mins and the
end of the day, and I'm sure the bug count and performance impact will
reflect that :-)

Anyhoo, here goes.......

In org.exolab.castor.jdo.Database, I added:

public void flushPersistenceCache(Class objectType);

The implementation of this method was added to
org.exolab.castor.jdo.engine.DatabaseImpl:

public void flushPersistenceCache(Class objectType)
{
    LockEngine engine = getLockEngine();
    engine.flushCache(objectType);
}

On org.exolab.persist.LockEngine, I added:

public void flushCache(Class objectType)
{
    TypeInfo info = (TypeInfo) _typeInfo.get(objectType.getName());
    info.clear();
}

To be clear, the TypeInfo class used in this method is LockEngine$TypeInfo
(inner class), not org.exolab.castor.mapping.loader.TypeInfo.

So, in LockEngine$TypeInfo, the implementation of clear() looks like this:

private void clear()
{
    cache.clear();
}

Since cache is of type org.exolab.persist.LRU, I added a clear() method to
the LRU abstract class, and implementations to each of the concrete classes:

org.exolab.persist.LRU:
public abstract void clear();

org.exolab.persist.LRU$CountLimited:
public synchronized void clear()
{
    keys = new Object[size];
    values = new Object[size];
    status = new int[size];
    mapKeyPos.clear();
    cur = 0;
}

org.exolab.persist.LRU$TimeLimited:
public synchronized void clear()
{
    map.clear();
}

org.exolab.persist.LRU$Unlimited:
public synchronized void clear()
{
    map.clear();
}

-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

Reply via email to