Richard Monson-Haefel wrote:
>
> Rickard �berg wrote:
>
> > Hey
> >
> > Chuck Zheng wrote:
> > > I know this is an implementation specific question. But I am interested
> > > in knowing what strategies vendors are using to minimize resoruce
> > > consumption therefore improve scalability.
> >
> > I'm fiddling with an approach that instead uses 1 (one) EJBHome and 1
> > (one) EJBObject per bean. If you think 5 minutes about it is is not that
> > hard to figure out how to do it, and it is *much* more efficient IMHO
> > than the brute force method. In this case you would never have to worry
> > about DGC or such issues, because you would never have idle EJBObjects
> > around. A nice sideeffect is that you can entirely skip the "create
> > container-specific EJBObject implementations"-phase.
> >
> > /Rickard
>
> Back in April of this year there Per Spilling started a short thread talking
> about this very topic. I have provided link (below) to the posting in the
> archive. To follow this thread to its conclusion clicking on the "Next in
> topic" link in the view section at the top. I think you will find this
> discussion very informative.
I have a few comments, observations and vendor pitches that may be of use in
this discussion.
(1) It would help if folks would use the term EJBObject only to refer to the
client's stub/proxy (object reference), and EJBHome only to refer to the
client's home stub/proxy (object reference).
(2) In some architectures there is an object that sits (in the server) between
the client's EJBObject and the bean instance. Let's say this 'implements' the
remote interface and delegates to the bean instance.
Some folks like to call this the EJBObject, but that is confusing as we
are then overloading the term EJBObject with two completely different
meanings. Let's call this the "wrapper object" to avoid confusion below.
Part of the discussion seems to regard how many "wrapper objects" exist for
each EJBObject, e.g. there may be one "wrapper object" for each EJBObject,
or there may be just one "wrapper object", regardless of the number of
EJBObjects (referred to as 1:1 and 1:N in the archives).
Or, there may be no "wrapper objects". In terms of the CORBA POA, the server
can treat the "bean instance" as the "POA servant", as long as the EJB
semantics are preserved. This eliminates any requirement for DGC. Note: this
is not very different from the 1:N approach in terms of resource consumption
and DGC, but it is definitely faster, as the delegation step is removed.
<vendor>
Sybase EAServer uses this technique.
</vendor>
(3) In some architectures, what is important is at what times does there exist
a direct association between an EJBObject and "bean instance". For example,
an association may exist when a transaction is active involving a particular
EJBObject, or for the EJBObject corresponding to an instance of an active
stateful session bean. The association between an EJBObject for an entity
bean instance would be broken when the "bean instance" is pooled, or for
a stateful session bean when the "bean instance" is passivated. For a
stateless session bean, no association is required.
Such an association would typically be represented internally as a
lightweight object, held in a hash table, keyed by the object key in the
EJBObject (client's object reference).
<vendor>
Sybase EAServer uses this technique.
</vendor>
(4) As far as EJBHomes are concerned, there is no need to have ANY objects in
the server to support these, apart from the bean instances to which most of
the work is delegated. (This is not very different from using a 1:N
approach though, it just avoids double delegation).
<vendor>
Sybase EAServer uses this technique.
</vendor>
The key observation that is required to get optimal scalability is that the
only memory-consuming 'objects' that are required by the EJB spec are the
client's stub/proxy objects (EJBHome/EJBObject) and the bean instances.
Anything else is "vendor specific stuff" that consumes valuable memory and
either slows down (typical with delegation) or speeds up (typical with
lightweight association objects) remote invocations.
________________________________________________________________________________
Evan Ireland Sybase EA Server Engineering [EMAIL PROTECTED]
Wellington - New Zealand +64 4 934-5856
===========================================================================
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".
