Imre Kifor wrote:
>
> 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).
This has to be done in all cases. You get a CDR encoded bytestream
from the socket. You will have no option but to consult a hashtable
of active object implementations to deliver the message to. This
cannot be avoided. Our solution of activation is in addition to this
setup. If the object is not found in this hashtable, activate it.
Second, delays due to synchronization are noise compared to network
and database delays. We ran our ejb tests with hotspot and saw pretty
much no improvement. (Perhaps it also suggests that the code is as
optimized as it can get!)
> 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.
You don't need to keep the pk around at all. The IOR has all the state
required. When the request comes in, you extract the pk from the IOR,
check your hashtable to see if the EJBObject exists. If it does, you
continue as before. Else, get an EJBObject from the pool, activate it
with the pk in question, put it in the hashtable and continue.
-Sriram
BEA/Weblogic
===========================================================================
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".
