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".
