I am not a lawyer myself.

I see lack of customization in java.util.WeakHashMap as a bug/RFE. Java Collections 
were meant to be customizable.

Look at Sun's bug parade:

http://developer.java.sun.com/developer/bugParade/bugs/4809420.html
http://developer.java.sun.com/developer/bugParade/bugs/4500542.html

(it is a known issue and there are some talks to introduce "WeakIdentityHashMap").

May be it will be possible to use this class without apache header until Sun releases 
updated version of WeakHashMap?


----- Original Message ----- 
From: "Armin Waibel" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, December 24, 2003 7:46 AM
Subject: Re: Usage WeakHashMap in AnonymousPersistentField Re: Cache and prefetched 
relationships


> Hi Andy,
>
> I got your IdentityWeakHashMap. Many thanks for this contribution, but ...
>
> I'm not a lawyer, but your "copy paste" solution from sun's WeakHashMap
> implementation could be problematic. We had have problems with Sun corp
> a year ago with copied code in JDO prototype, so I don't like to check
> in code that may violates Sun's copyright.
> This is my humble opinion - any comments?
>
> regards,
> Armin
>
> Andy Malakov wrote:
>
> > 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]
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> 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]

Reply via email to