Dave,
Can you elaborate a bit more on the process that EJBObjects are not created
as a part of findBy<Something>() then when are these objects created. I mean
when we get a collection of objects at the client-end and we call some
business method on one of the elements from the collection, in this process
where exactly the EJBObject is created.
Rajan
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Evan Ireland
Sent: Tuesday, November 28, 2000 5:30 AM
To: [EMAIL PROTECTED]
Subject: Re: EJB Object implementation
Christopher Cobb wrote:
>
> So if these nice app servers are doing all this work for us, to what
extent should the typical applications developer be concerned with issues of
multiplicity of objects. And what general design patterns should we follow
to keep our multiplicity low?
The main pattern is this respect is "don't use a stateful session bean
where a stateless session bean would suffice".
> cc
>
> Dave Wolf wrote:
>
> > Sybase EAServer is also similar. We create no EJBObject instance. We
do
> > have some internal objects as part of our dispatcher code, but they are
not
> > exact analogs of the EJBObject. To use the EJBObject is simply a
logical
> > idea.
> >
> > Our product is more TIE based so we do have a skeleton but again not an
> > EJBObject.
> >
> > Dave Wolf
> > Internet Applications Division
> > Sybase
> >
> > ----- Original Message -----
> > From: "Jonathan Weedon" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, November 27, 2000 5:37 PM
> > Subject: Re: EJB Object implementation
> >
> > > Rickard,
> > >
> > > I am so excited: we agree!
> > >
> > > <vendor>
> > >
> > > I very much agree with Rickard that creating anything in the server to
> > > represent each object is a waste of resources. Likewise, our product
> > > avoids doing so, and thereby avoids the associated memory overhead.
> > >
> > > I am curious what other vendors have this capability, if any. That
is,
> > > what is the incremental cost of instantiating a new object over the
long
> > > run? For example, if there are N Stateful Session Beans in the
> > application,
> > > is there a O(N) memory requirement? In our server (and JBoss) there
is
> > > not, only a O(N) disk space requirement (which is needed to store the
> > > passivated beans). If the memory required is linear with the number
of
> > > objects, obviously the server cannot truly scale.
> > >
> > > Unfortunately, you can't read our source code to see how this is done.
> > > But you can read the OMG's Portable Object Adapter specification,
which
> > > outlines the server-side dispatch-model of our CORBA product, on which
> > > our AppServer is built.
> > >
> > > </vendor>
> > >
> > > -jkw
> > >
> > > Rickard �berg wrote:
> > > >
> > > > On Mon, 27 Nov 2000 09:55:33 +0500, [EMAIL PROTECTED]
> > > > wrote:
> > > > >**In short when u call create() on home interface the container
creates
> > > > >a EJBObject and associates it with a class instance from the
pool.(the
> > > > >primary key is the binding factor between the two.)
> > > >
> > > > <vendor>
> > > > Note that when you say "create an EJBObject" that does not
necessarily
> > > > mean that a physical object is created on the server. That is *one*
> > > > implementation option, and in the case of JBoss we have chosen *not*
to
> > > > create such objects since it affects scalability negatively.
> > > >
> > > > For example, you can have a finder method return an enumeration of
> > > > 1.000.000 EJBObjects. This does *not* mean that there are now
1.000.000
> > > > objects being created on the server, since that would be a serious
> > > > resource drain.
> > > >
> > > > For more information I suggest you simply read the source code for
our
> > > > server. It's all there. See www.jboss.org for details on source
> > > > download.
> > > > </vendor>
> > > >
> > > > /Rickard
> > > >
> > > > --
> > > > Rickard �berg
> > > >
> > > > Email: [EMAIL PROTECTED]
> > > > http://www.telkel.com
> > > > http://www.jboss.org
> > > > http://www.dreambean.com
> > > >
> > > >
> >
===========================================================================
> > > > 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".
> > >
> > >
> >
===========================================================================
> > > 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".
> > >
> > >
> >
> >
===========================================================================
> > 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".
>
>
===========================================================================
> 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".
--
____________________________________________________________________________
____
Evan Ireland Sybase EAServer 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".
===========================================================================
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".
