Re: [Patsystem-users] what about object deletion?

[<vla...@ip...>]

Hi


>> =BFhow does PAT handle the "old objects eat all ram" issue?

>PAT doesn't. You can.
>Just write on OID down, and use
>((org.nthx.pat.Persisteble)root).removeBO(oid);
>in the appropriate moment..

I reaally wish I dont have my business objects (where logic belongs) =
coupled/aware_of  org.nthx.pat.Persisteble.


>I was looking at WeakHashMap, but it isn't serializable (I don't know =
if
>making it Serializable would cause sth extra..), and second: I'm not
>sure how exactly does it work when (de)serializing such IdentityMap.
>
>If you have some experience on that, share it here.

weakHashMap definitelly won't cut it.
weakhashmap holds soft references for the KEYS, which in PAT case's are =
the OIDs.
As soon as no one holds a strong refference to any OID, the OID key will =
be removed from the map and thus the BO (map value). this is not what we =
want because most likely OIDs are not used, pure pojo references are. =
composite objects instead of DB foreign keys.

jakarta commons collections offers Maps that hold soft or weak =
references on the Values rather than the keys.
this means that if a BO is not reachable from another BO (meaning, it =
can't be reached indirectly from the root), only then could it be GC'd. =
I think this is what we want.

Using jakarta common's collections ReferenceMap, the difference between =
weakreference and softreference lies only in timing:
* an object being weak referenced is erased as soon as the object is not =
reachable (by other "real" strong refferences).
* an object being soft referenced is not erased immediatly when it =
becomes not reachable, but later, when (if) memory gets tight.

Dont even consider using sun's default weakhashmap.

>Here is example on the problem I just can't solve..
>I'm not sure how all weak hashMaps solve following problem:

>Map consists of two 4 keys-values:
>1 -> root                (we need to keep that object)
>2 -> root.child
>3 -> other               (this should be garbage collected soon)
>4 -> other.andHisChild

>'root' is our ROOT. Object 2 is referenced by root and stored in IM
>(IdentityMap). Object 3 however, is stored in IM (cause it was created)
>but is not referenced by anyone and should be removed in the next
>session.

>So we close application, take snapshot, open application,  and what =
will
>happen? How can any weak hashMap recognize to remove 'other' (among =
with
>his children) and not 'root' (with children)?=20

>There are no references to OID: 1 and OID: 3.

Only sun's weakhashmap needs references to OID's.

If you use jakarta commons, all you need is to somewhere hold areference =
to root. root itself holds references to its children, and they do the =
grandchildren. If any normal business logic makes an object unreachable, =
then it should be garbagecollected (BO's dont want to go to identitymap =
and look for it).
No object reachable from root will ever be garbage collected. Maybe  =
RootCreationInterceptor can arrange for there being a strong reference =
to root somewhere, or maybe we need to turn root into a singleton object =
(referenced by its class, in a static field).


>I think there might be some tricky hack to that. I just didn't have =
time
>and didn't care. If you really need this we can think of it. I would be
>happy to see the solution and apply it to PAT. Want to contribute?

>:)

If i'm not wrong, it should be rather easy:
changing IdentityMapMixin's constructor to not use:

 public IdentityMapMixin()
    {
        uniqueOID =3D 1L;
        map =3D new HashMap();
    }

but instead:

 public IdentityMapMixin()
    {
        uniqueOID =3D 1L;
        map =3D new org.apache.commons.collections.map.ReferenceMap;     =
  // should use a map with strong keys and soft values.
    }


... of course, then add a new library, include it's license text etc.