I've found a solution for this problem, and wanted to update the list in case anyone is interested. I will say up front that my solution does not really address the base problem. I'm kind of surprised that this problem hasn't come up before (or generated more interest than this thread has). I would think that it is not uncommon for classes to implement multiple interfaces, and to therefore participate in multiple extents. Of course, we didn't encounter the problem for over a year! ;-}
Anyway, my solution (with help from Dave Corbin) depends on the fact that we had implemented our own cache implementation. This cache class has a static HashMap for caching objects keyed by Identity, as usual. I added an additional static HashMap that maps classNames to a List of topLevelClasses. When the constructor is called, if this Map hasn't been populated, it is populated by retrieving the DescriptorRepository from the PersistenceBroker. I iterate over the list of descriptors, and for each one that has a populated extentClassNames table, I iterate over that. For each className in the extentList, I make sure that the Map contains an entry keyed by that class. I then make sure that that entry's list contains the topLevelClass of the class described by this classDescriptor. After the Map is populated, I remove all entries where a class participates in only one extent. Now, when an object is cached, if there is no entry in the extent Map, it is added to the cache in the usual manner. Otherwise, an Identity object is created based on the first class in the list, and the object is cached with that Identity as key. Then for each additional class in the list, an Identity object is created, and a cache entry is created mapping that Identity to the Identity that keys the actual object. When retrieving an object form the cache, I just have to check if I have retrieved an Identity or another object. If I retrieve an Identity, I just use that to retrieve the actual object. There is also additional code to handle removal, and "dead links". This has resolved the problem of having 2 copies of the same "object" in the cache, keyed by different identities, and my app works as it should. But I am concerned that this seems like a basic enough problem that I would prefer to see it addressed in the OJB core, rather than depending on a specific cache implementation. I would be willing to work on this if others are also concerned, and believe that it would be worthwhile. Sorry for the long post. Thanks for listening. Dave D ----- Original Message ----- From: <[EMAIL PROTECTED]> > Hello, > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > I have just encountered a situation that I THINK is a bug in > > the Identity > > object. The equals method compares the topLevelClass, and I > > think it should > > be comparing the realClass. > > I think others have explained why this cannot work. > The realClass might be unknown when the identities are compared. > > > I'll try to explain my situation, and I HOPE that I can do so clearly. > > > > I have a class AB, which derives from abstract class A, and implements > > interface B. > > this is a case where the topLevelClass is not determined uniquely. > > I think OJB cannot handle this correctly. This problem is addressed, > too, in the current thread "Identity.realClass set to abstract class?!" > in the developers' list. > > As a workaround, you might wish to introduce an artificial > top-level class for each connected component of you inheritance tree. > Than this will be the topLevelClass for all references to classes > in that hierarchy. But watch out: depending on your mapping, this > may result in a serious loss of performance, because when resolving > a reference to an object of such a class, all tables of classes > of that object will have to be searched in. > > Olli --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
