Hello Armin,
I will send you my version of IdentityWeakHashMap (nothing in there to be proud of ;-).
> What about using a wrapper object for all keys and override 'equals'
I saw this solution in o.a.ojb.broker.util.IdentityHashMap.
I do not think we should use wrappers in this case - AnonymousPersistentField cache
entries are created in large amounts and have
very short life.
Thanks a lot for all support,
Andy
----- Original Message -----
From: "Armin Waibel" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, December 23, 2003 2:35 PM
Subject: Re: Usage WeakHashMap in AnonymousPersistentField Re: Cache and prefetched
relationships
> Hi Andy,
>
> do you mean we should implement a IdentityWeakHashMap?
>
> What about using a wrapper object for all keys and override 'equals'
> method to do a obj==obj comparison?
>
> class IdentityKey
> {
> Object obj;
>
> public IdentityKey(Object obj)
> {
> this.obj = obj;
> }
>
> public boolean equals(Object obj)
> {
> if(obj instanceof IdentityKey)
> {
> return this.obj == ((IdentityKey)obj).obj;
> }
> else return false;
> }
>
> public int hashCode()
> {
> return System.identityHashCode(obj);
> }
> }
>
> regards,
> Armin
>
> Andy Malakov wrote:
>
> > Workaround: Replacing WeakHashMap by IdentityWeakHashMap in
> > AnonymousPersistentField.fkCache.
> >
> > IdentityWeakHashMap (similarly to java.util.IdentityHashMap) uses
> > reference-equality in place of object-equality when comparing
weak
> > keys. Unfortunately WeakHashMap has most of the relevant methods as
> > private/package-private and code has to be duplicated.
> >
> >
> >
> > ----- Original Message -----
> > From: "Andy Malakov" <[EMAIL PROTECTED]>
> > To: "OJB Users List" <[EMAIL PROTECTED]>
> > Sent: Monday, December 22, 2003 8:10 PM
> > Subject: Usage WeakHashMap in AnonymousPersistentField Re: Cache and prefetched
> > relationships
> >
> >
> >
> >>Hello All,
> >>
> >>I found that usage of database identity in Java produces quite interesting problem
> >>in OJB:
> >>
> >>In my application all persistent Java objects use database identity instead of
> >>Java reference identity (i.e.
Persistable.equals()
> >
> > is
> >
> >>redefined so that two persistent objects are the same if they have the same
> >>primary key and top-level class).
> >>
> >>In OJB, for each field declared in repository there is dedicated instance of
> >>AnonymousPersistentField that stores
> >>object-to-field-value mapping in WeakHashMap (in fkCache attribute).
> >>
> >>Despite usage of cache (ObjectCachePerBrokerImpl in my case) it is possible that
> >>identical DB objects will end up as different
> >
> > Java
> >
> >>objects during retrieval of complex objects.
> >>
> >>Now imagine what happens when two identical instances are retrieved:
> >>
> >>1). When first instance is retrieved it stores its foreign keys in
> >>AnonymousPersistentField.fkCache under instance's identity.
> >>(happens in RowReaderDefaultImpl.buildWithReflection())
> >>
> >>2) When second object is retrieved and stored in fkCache, first instance is
> >>probably still cached [WeakHashMap entries are
cleaned
> >>up only during GC]. Since keys are identical WeakHashMap only updates entry value
> >>and DOES NOT update entry key.
> >>
> >>3) If Full GC happens after that moment it will dispose fcCache entry if the FIRST
> >>reference becomes soft-referenced only.
> >>
> >>Can you please comment on this issue?
> >>
> >>BTW From OJB client side it looks like loaded objects randomly appear without
> >>their childen. Spooky :-)
> >>
> >>May be the real problem is duplicate instances of the same objects?
> >>
> >>All the Best,
> >>Andy
> >>
> >>p.s. An additional thing - will it be possible to add fast assertion into
> >>ReferencePrefetcher.associateBatched() that will
verify
> >>that all parent objects found their children in case of non-null FK?
> >>
> >>CollectionPrefetcher, line 117:
> >>
> >>+ boolean childFound = false;
> >> for (Iterator it2 = children.iterator(); it2.hasNext(); )
> >> {
> >> relatedObject = it2.next();
> >> id2 = new Identity(relatedObject, pb);
> >> if (id.equals(id2))
> >> {
> >> field.set(owner, relatedObject);
> >>+ childFound = true;
> >> break;
> >> }
> >> }
> >>
> >>+ if ( ! childFound)
> >>+ throw new Exception ("!!! Unresolved reference: " + id + " from "
> >>+ owner);
> >>
> >>
> >>
> >>
> >>------------------------------------
> >>Re: Cache and prefetched relationships
> >>From: Oleg Nitz
> >>Date: Mon, 06 Oct 2003 00:16:10 -0700
> >>
> >>Hi Carlos,
> >>
> >>On Sunday 05 October 2003 14:37, carlos wrote:
> >>
> >>>broker.getCollectionByQuery(): Optimised prefetched relationships are only
> >>>useful if object caching is enabled.
> >>>
> >>>Also, using the default cache, it appears that any related objects obtained
> >>>by an optimised SQL IN() clause may be 'garbage collected' before being
> >>>assigned to the 'owning object', causing another database lookup at
> >>>assigment. I believe I've observed this behaviour retrieving many objects
> >>>(2000+) - Is this correct?
> >>
> >>Looking at the ReferencePrefetcher implememntation, I see that this is
> >>possible for references (not for collections). Also I see that this problem
> >>can be easily fixed. I'll do this.
> >>
> >>Thanks,
> >> Oleg
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
