To answer your question abt. Container avoiding a call to ejbStore(), you
can achieve that,
by using the isModifiedMethodName property of deployment descriptor and
implementing the method to return false.The
server calls this method after calling the actual method (in your case its
sneaky() ) and calls ejbStore() only if this method returns true.
The syntax I specified above is for weblogic, but other ejbservers should
be having a similar concept.
But one thing I do not understand here, is when your myStuff variable is
not mapped to db column,
how does it matter whether ejbStore() is called or not ?
Or am i missing something here....
Rgds.,
komal.
Avi Kivity
<avi.kivity@TALMA To: [EMAIL PROTECTED]
I.COM> cc:
Sent by: A Subject: Re: Does it ever make sense
to put a
mailing list for multi-bean-returningfindmeth odin an
entity bean?
Enterprise
JavaBeans
development
<EJB-INTEREST@JAV
A.SUN.COM>
09/04/00 02:36 AM
Please respond to
A mailing list
for Enterprise
JavaBeans
development
> -----Original Message-----
> From: Jonathan Weedon [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 01, 2000 22:17
> To: [EMAIL PROTECTED]
> Subject: Re: Does it ever make sense to put a
> multi-bean-returningfindmethodin an entity bean?
>
>
> Avi Kivity wrote:
> >
> > >
> > > I believe both you and Avi are confusing what
> ejbPassivate/ejbActivate do on
> > > entity beans with what they do on stateful session beans.
> For stateful session
> > > beans, after ejbPassivate is called, the bean is
> serialized and stored to
> > > some persistent storage (typically, to the file system,
> perhaps via a database).
> > > For entity beans, however, after ejbPassivate is called,
> the entity does not
> > > have to be serialized, or stored on disk, or anything
> else. It simply moves
> > > from the "ready" bin to the "pooled" bin, which is
> probably a fairly trivial
> > > operation. There should not be any memory or disk
> overhead associated with a
> > > passivated entity bean, and thus it is certainly not
> computationally expensive
> > > to passivate.
You are correct - entity passivation indeed does not require serialization.
This leads to a new question: is the container required to call ejbStore()
even if no CMP fields have been modified, or can the container avoid the
call? Suppose doit(), below, is replaced by ejbStore(). Is the code still
broken? If so, then a nice chunck of my own code needs rewriting.
> >
> > Can you explain why EB passivation is so different?
> Consider the following:
> >
> > public class EB implements EntityBean {
> >
> > public int cmpField;
> > private int myStuff;
> >
> > // ...
> >
> > public void sneaky() {
> > myStuff = 42;
> > }
> >
> > public void doit() {
> > cmpField = myStuff;
> > }
> >
> > }
> >
> > Now suppose a client calls, in a single transaction,
> sneaky() and then
> > doit(). How can the container passivate the instance
> between those method
> > calls without losing data? Or is "private int myStuff" illegal?
> >
> > As a matter of fact, I have many lazy stores (where doit()
> is actually
> > ejbStore()). Are they all broken?
>
> Avi,
>
> It is legal, in EJB 1.1, for the above two methods to be executed as
> follows:
>
> begin transaction
> EB[1].ejbActivate()
> EB[1].ejbLoad()
> EB[1].sneaky();
> EB[1].ejbStore();
> EB[1].ejbPassivate();
> EB[2].ejbActivate();
> EB[2].ejbLoad();
> EB[2].doit();
> EB[2].ejbStore();
> EB[2].ejbPassivate();
> commit transaction
> // nothing to do here since ejbStore was already called...
>
> By this I mean that the method sneaky() is executed on on
> instance of EB (that
> is, EJ[1]) and doit() is executed on another instance (that
> is, EB[2]). Not
> that I am saying that this is a good way to write a
> container: it is not.
> However, if your code cannot run in this mode (where every
> entity bean method
> could potentially be executed on a different instance) then
> your code is not
> compliant with the EJB spec. Sorry, but it appears the your
> "private int myStuff"
> is illegal (or at least will contain undefined values),
> unless you convert it
> to a state-managed field in ejbLoad and ejbStore.
>
- Avi
--
s/\be(\w+)/e-\1/g;
===========================================================================
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".
