Sriram,
>DGC is a non-issue if you take activation into account. You can encapsulate
>any info you want in an IOR, which in the case of an EJBObject is
>the home and the primary key. Since the EJBObject can be activated any
>time a request comes in, and since all required state is part of the
>IOR, you don't need the EJBObject to sit around occupying memory.
>Further, since the server reserves the right to deactivate this object
>at will, there's no need for GC or for weak references or whatever.
>
>This is fast, extremely scaleable, and doesn't *require* Java2.
No question, your "activation" is a very clever solution to the problem at
hand (i.e. no weak references in JDK1.1). However, it also means that every
remote call to entity objects has to be channeled through a *synchronized*
table of already activated objects (which is a classic bottleneck in my book
especially considering multiple processor servers).
Unless, of course, you allow multiple entity objects associated with the
same PK. In this case, however, you still need to synchronize at one point
on a *collection* of entity objects to provide correct calling semantics
(i.e. see above bottleneck).
Also, since you must encode PKs (to avoid transferring user defined, i.e.
possibly large, objects with every call), you also have to keep a table
around for decoding your calls. And the table cannot be GCd, hence we are
back to our resource management problem where you cannot release user
defined objects.
Am I wrong?
Imre Kifor
Valto Systems
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
