Usually when we start putting the function in the session bean , we first
consider the logical division. If the function are related to each other
then we tend to put them in one bean.How ever as soon as these fn keep on
increasing and the frequency of the hits for fns differs greatly with each
other then we can again subdivide them in another session bean.This will
allow us finer control over each bean. For eg. we can increase the no of
instances in the pool for session bean containing fn which have high no of
hits without affecting the other session bean.
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Piyush Nigam
Sent: Tuesday, August 07, 2001 9:23 AM
To: [EMAIL PROTECTED]
Subject: Re: How coarse is a bean to be?
The question is to define what can be considered 'related'. If the methods
involved are always called independant of each other but are very similar
business processes then do we consider them related and thus place them on
the same bean. Also consider that there might be varying trafic load on
each of the functions... doesn't placing them in separate beans give us a
chance to fine tune the performance of the application?
Piyush Nigam
Avi Kivity
<avi.kivity@TALMA To:
[EMAIL PROTECTED]
I.COM> cc:
Sent by: A Subject: Re: How coarse is
a bean to be?
mailing list for
Enterprise
JavaBeans
development
<EJB-INTEREST@JAV
A.SUN.COM>
08/06/2001 09:39
PM
Please respond to
Avi Kivity
>
>
> Hi,
> How coarse do we make our session bean? I have three business
> methods which
> are similar in nature, require the same entity beans for
> their execution.
> Option one:
> Put three remote methods in my session bean, one for each business
> requirement and keep one session facade. This makes for
> heavier components
Also increases code reuse.
> but reduces the number of different beans that the container
> has to manage
> Option two:
> Make three separate session beans which connect to the same
> entity beans.
> Lighter session beans but greater in number
This is not really an issue. The number of _instances_ in memory only
depends on the number of inflight calls (assuming stateless SBs, otherwise
the semantics change). The number of calls does not depend on your
partitioning.
>
> Which one is better?
>
If they are related, put them together. If they are unrelated, separate
them. Performance is not a factor here.
- Avi
--
This signature intentionally left blank.
===========================================================================
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".
