Hi Dave,
It would be a very good idea to do this if we got some way of setting
the container to serve us the same (phisycal) instance of the stateless
session bean. But this isn't the case.
First, how to change data when using stateless session bean instead of
entity + DAO?
- Issue a select request to read and view data intended to be changed.
Stateless beans need one DB-Call, entity bean need two: for ejbFind and
for ejbLoad (if the bean isn't in the memory).
- Then issue an update request (maybe through another stateless bean
instance). Here entity bean and stateless bean yield the same
performance (since entity bean no longer need lookup call.
One more advantage for stateless bean in this approach: Data are locked
at the DB level, providing a feiner locking granularity.
Drawbacks: you lost the statefull capability of entity beans.
1. Stateless beans can't keep transaction accross method call. So you
can't safetely perform more than one operation into the same
transaction. If you try to start the transaction outside the bean, you
are exposed to the danger of blocking n stateless beans of the same type
into the same transaction (for n calls). This happens because the
container supposes that request to stateless bean are always from a
different client. So it can't reuse the stateless bean already involved
into the same transaction to serve you.
2. Entity beans do some kind of usefull data caching when they are well
modelled. The more common situation is to use entity beans that
represent real live actors (Employee, BusinessPartner, Customer) or
object belonging to them (Contract). This kind of entity bean are often
loaded once by the actor and more often browsed than changed. So after
the first lookup (2 DB calls), many "get requests" are sent to the bean
(no DB calls). If you use stateless bean here, you will send it to the
DB for each get request (no caching capability). But also notice that
this kind of entity beans are less shared. For a typical entity bean
like a "Company" that suffer under intensive concurent read access, I
would use stateless bean (+ DAO cache).
Some rules:
- Never use session beans to model person related actors like Employee,
Customer, Person as well as object belonging to them (Contract). This
rule is derived from the fact that these beans are used by actors
themselve or some actors in relationship with them (i.e. an employee
trying to get the address of his coleague). Concurent access is rare.
Interactive use happens more often (the employee will first check the
email address of the coleague and direct after that, check his calendar
to synchronize a schedule).
- Replace entitity beans with stateless beans (+ DAO and readonly
cache) for real live objects exposed to intensive concurent access (like
a StockBean that is currently accessed by thousand of speculators).
- Replace entity beans by stateless beans for "objects" that are less
interactive and often subject of mass update. The more current using
logic should be: lookup a list of row ids, iterate the list and update
each row. Using stateless beans for this purpose, you save a lot of
useless ejbLoad calls.
/Francis
Dave Wolf 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.
>
> Dave Wolf
> Internet Applications Division
> Sybase
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Francis Pouatcha
> > Sent: Monday, September 18, 2000 7:04 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Reason for using entity beans
> >
> >
> > Hi Dave,
> > can you please clarify what you mean with this:
> >
> > > Whats the negetive with using Stateless session beans to do the
> > actual query
> > > itself, and then have the EntityBeans make calls into them? In that way
> > >
> > > 1) All data access code is still in one place, the session beans
> > > 2) The data manipulation and read is still available outside of
> > the entity
> > > bean for direect access if needed?
> > >
> > /Francis
> > --
> > [EMAIL PROTECTED]
> >
> > MATHEMA Software GmbH
> > N�gelsbachstra�e 25 b
> > 91052 E r l a n g e n
> > D e u t s c h l a n d
> > Tel +49(0)9131/8903-0
> > Fax +49(0)9131/8903-55
> > http://www.mathema.de
> >
> > ==================================================================
> > =========
> > 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".
--
[EMAIL PROTECTED]
MATHEMA Software GmbH
N�gelsbachstra�e 25 b
91052 E r l a n g e n
D e u t s c h l a n d
Tel +49(0)9131/8903-0
Fax +49(0)9131/8903-55
http://www.mathema.de
===========================================================================
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".
