Sriram,
>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.
Agreed. However, it seems that entity beans usually come in two flavors. One
flavor with many instances and a small number of calls per instance and the
other with few instances but frequent calls per instance (e.g.
concentrators). The above approach forces calls on all entity objects
through the same socket, thus eliminating possible parallelism dispatched on
the OS level. Hence, I doubt that the latter flavor of entity beans would be
handled optimally on multi-processors by the above approach.
>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!)
I wouldn't take synchronization lightly. I can easily think of situations
where cached (i.e. no db access) peer (i.e. no network) beans chatter among
themselves for a while before returning a result to the client. In such
cases, any extra synchronizations on global tables will become noticeable
and expensive. Especially when thousands of concurrent clients are involved
and multi-processor servers are used.
>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.
This means that with every remote call to entity objects, you also have to
transfer user defined (i.e. possibly large) PK data that on the receiving
end has to be recreated and, hopefully most of the time, discarded right
after a quick comparison. I have to admit that, with your approach, entities
with non-trivial PKs could become more expensive than session beans and
using session bean wrappers would then be necessary.
HOWEVER, the requirement for wrapping entity beans is caused by your
specific implementation and should not be considered as a generic, EJB
design pattern.
After understanding and appreciating the details of your implementation (in
light of the limitations of JDK1.1), I have to say that I still prefer an
approach where calls are as fast/parallel as possible, only the minimum
required data is transferred/created during a call and cleanup happens
transparently in the background following usage spikes.
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".
