This is really interesting.
Again the hassle is that our design will differ depending on different
vendors implementations. I suspect that many vendors will try and minimise
the cost of object calls (but to differing extents depending on their
algorithms) and again the JVM in use may lead to lesser or better GC.
Any other <vendor> </vendor> comments ?
cheers,
eddie
=========
At 10:23 19/09/00 -0400, you wrote:
>Well, I did a little testing. First off, lets not get into a BMP vs CMP
>discussion. My proposal was simply that if doing BMP, would stateless
>sessions be a better choice then lite data access classes.
>
><VENDOR>
>
>Using Sybase EAServer 3.6 and EJB 1.1
>
>I create some very simple entities and session beans and simple classes. I
>simply tested having the entity call the session bean vs. the entity create
>an instance of a simple data access class directly. In my tests, which I
>will admit were fast and dirty, I found no real measureable difference
>between the inter bean call, and direct instantiation. Remember as I said,
>in EAS inter bean calls on the same container occur via an in-memory IIOP
>call so there is no network overhead. So, the overhead of pulling the bean
>out of the cache and the interbean communications is no worse then the
>overhead of instantiating the object. HOWEVER I did find an interesting
>side effect. If I ran the tests for a long time, the interbean call was
>faster over the long run. I originally thought there was just a small
>difference I had just considered noise, but became a real difference over
>time, but I think the actual issue is garbage collection. See, with pooled
>stateless beans, the beans themselves never need to be gc'd, they remain in
>scope at all times. But my simple data access classes DO fall out of scope
>(I assumed no static caching as I believe this violates the spec). So the
>overhead of the eventual gc was more then the stateless bean, as the
>dataobjects get collected.
>
>This could obviously be resolved by trying to hold strong references to
>these data objects in a free-list and reusing them, but again, we stumble
>into the gray area of static caching.
>
></VENDOR>
>
>Just my $0.02
>
>Dave Wolf
>Internet Applications Division
>
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Eddie Fung
> > Sent: Tuesday, September 19, 2000 2:03 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Reason for using entity beans
> >
> >
> > Dave,
> >
> > i like this idea for re-usable data objects (be they Session Beans or DAO)
> > with some qualification. The questions you raised:
> >
> > >>1) What is the overhead of instantiation vs an in-memory inter
> > bean call
> > I'd expect this would vary from container to container. The interesting
> > thing is that I gather that some containers capture the remote
> > call and, if
> > they know the call can be satisfied locally, turn it into a local call,
> > saving some network overheads. I still think that object creation and
> > instantiation would be faster than using Session Beans even if
> > the SB's are
> > pooled but that's not on the basis of any container experience.
> > Does anyone
> > know what the costs are at container level ? <vendor> </vendor> responses
> > very welcome !!
> >
> > >>2) Would DAO be available directly from a client source? No,
> > you would have
> > >>to facade anyways inside a session bean.
> > Obviously this would be a design guideline to reduce the network overheads
> > of SQL calls from client to server and to preserve MVC consistency.
> >
> > The fact that we are discussing this fairly basic design aspect shows us
> > how immature the persistence part of the spec is. However it does present
> > another level of data access consistency when one wants to access data
> > without going through the overheads of using EBs. Actually this raises
> > another point. Often times we have to build coarse EBs to encapsulate a
> > business object eg. Order (and it dependent OrderItems). Using DAO/Session
> > Beans to encapsulate the logic means that if we needed to we might be able
> > to access dependents within an EB without having to go to the cost of
> > instantiating the EB just to get to a dependent. This could be
> > good or bad.
> > If the application is built assuming Commit Option A then we are badly
> > subverting the spec with potential to cause data integrity
> > problems. Anyone
> > got any comments ?
> >
> > cheers,
> >
> > eddie
> >
> > ========
> > At 07:28 18/09/00 -0400, you wrote:
> > >I mean, why have inline SQL in the entity bean, or even helper
> > classes which
> > >manage the interaction with the RDBMS when you could have a
> > session bean do
> > >the same. For instance, the session bean would have insert(), delete(),
> > >select() and update() methods. Then you have
> > >
> > >session bean facade --> entity --> data access session.
> > >
> > >Now you can use the same session bean to do lookups, result set
> > listing etc
> > >and use the same logic from your entity bean.
> >
> > Snipped..
> >
> > >>1) What is the overhead of instantiation vs an in-memory inter
> > bean call
> > >>2) Would DAO be available directly from a client source? No,
> > you would have
> > >>o facade anyways inside a session bean.
> >
> >
> > >Dave Wolf
> >
> > ==================================================================
> > =========
> > 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".
