Hi Marc,
There are only a few behaviors mandated by the spec, such as
calling ejbStore when a transaction completes (but see Robert
Patrick's recent e-mail for an alternative point of view). Richard's
description is exactly right. Your scenario exists in the standard,
but as an example of a way that a server can support distributed
diamonds (11.7.2). Richard's reply points out other factors that
may make this constant persisting and reloading of state
necessary: transaction attribute of the method, database isolation
level, and concurrency mechanism. In general, calling ejbLoad and
ejbStore around every business method, rather than on transaction
boundaries, can have a significant performance penalty.
The specification actually says: "Invocations of the ejbLoad() and
ejbStore() methods can be arbitrarily mixed with invocations of
business methods." This is from the bean's point of view, of
course. A server can't actually call these methods arbitrarily and
expect correct behavior! But a significant amount of flexibility is left
to the server implementor. For instance, if the server has exclusive
access to the database, it can bypass a call to ejbLoad and
instead use a cached entity. This is specifically allowed in 9.1.1.0.
-Dan
On 11 Apr 00, at 5:22, Marc Naef-Lendvai wrote:
> Hi Richard,
>
> I thought that this was specified in the standard:
>
> within a transaction:
> - ejbLoad when entering a business method
> - executing business method
> - ejbStore when leaving business method
> commit of those changes only upon commit of the whole transaction in the
> container
>
> That's why one should not implement each object as a entity bean as the
> performance decreases with this behaviour...
>
> best regards
>
> Marc
>
> -----Original Message-----
> From: Richard Monson-Haefel [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 10, 2000 2:08 PM
> To: [EMAIL PROTECTED]
> Subject: Re: What determines when ejbStore and ejbLoad get called?
>
>
> DaveFord wrote:
>
> > What determines when ejbStore and ejbLoad get called?
> >
>
> This is dependent on how your server is implemented, but for most servers
> its
> the transaction boundaries that determine when the ejbLoad and ejbStore are
> called. When an entity bean is enrolled in a transaction (accessed within a
> transaction context) the ejbLoad is invoked to synchronize its state with
> the
> database before any business methods can be serviced. When the transaction
> ends, all the entity beans enrolled in the transaction have their ejbStore
> method invoked by the container so that they can write their changes to the
> database.
>
> Some vendors may choose to implement their servers so that the ejbLoad and
> ejbStore are called before and after (respectively) each method invocation.
> This approach consumes more resources and cycles but may ensure that the
> entity
> bean's state is more current depending on the transaction attribute,
> database
> isolation and concurrency mechanism employed (server managed concurrency vs.
> database managed concurrency).
>
> Richard
> --
> Richard Monson-Haefel
> Author of Enterprise JavaBeans, 2nd Edition
> Published by O'Reilly & Associates
> http://www.EjbNow.com
>
> ===========================================================================
> 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".
