Thanks Evan, I had not previously came across that in the spec, even though
I've (thought i had) read it dozens of times.
With the spec quoted, shouldn't the 2.0 spec authors disallow Supports,
NotSupported, and Never on entity beans. I am not usually an advocate of
protecting the developer from themselves, but this problem could be very
subtle.
jim
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Evan Ireland
> Sent: Tuesday, June 20, 2000 6:00 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Hole in the Spec (1.1 *and* 2.0)?
>
>
> James Cook wrote:
> >
> > I have been involved in an EJB debate involving transaction
> declarations and
> > entity beans. In the systems that I have been designing, the client
> > (application) will never have direct access to any entity
> beans. To simplify
> > design and deployment of my entity beans, I have decided to
> mark all methods
> > on entity beans as SUPPORTS. My session beans will control all
> transaction
> > semantics throughout the system. For the most part, bulk accessors and
> > readonly data will not be accessed within a transaction. All
> other methods
> > in my session beans are marked as REQUIRED.
> >
> > So much for the background.
> >
> > The problem is: The spec states (as far as entity beans are
> concerned) that
> > ejbLoad() will be invoked before a business method is called on
> an entity
> > bean, but only the first time it is used in a transaction. This sounds
> > reasonable enough. However, what happens when the bean is not
> called within
> > a transaction? The same vaguary exists for ejbStore().
> >
> > Shouldn't some entity bean accessors be able to be called outside of a
> > transaction? Is this type of access "undefined" by the spec.
> Should EJB 2.0
> > shore this up before it is final?
>
> My copy of the EJB 1.1 spec (public draft 2) reads:
>
> 9.1.7.1 ejbLoad and ejbStore with the NotSupported transaction attribute
> The use of the ejbLoad and ejbStore methods for caching an entity
> object�s state in the instance
> works well only if the Container can use transaction boundaries
> to drive the ejbLoad and ejbStore
> methods. When the NotSupported [7] transaction attribute is
> assigned to a remote interface method,
> the corresponding enterprise bean class method executes with an
> unspecified transaction context (See
> Subsection 11.6.3). This means that the Container does not have
> any well-defined transaction bound-aries
> to drive the ejbLoad and ejbStore methods on the instance.
> Therefore, the ejbLoad and ejbStore methods are �unreliable� for
> the instances that the Container
> uses to dispatch the methods with an unspecified transaction
> context. The following are the only guaran-tees
> that the Container provides for the instances that execute the
> methods with an unspecified transac-tion
> context:
> The Container invokes at least one ejbLoad between ejbActivate
> and the first business
> method in the instance.
> The Container invokes at least one ejbStore between the last
> business method on the
> instance and the ejbPassivate method.
> Because the entity object�s state accessed between the ejbLoad
> and ejbStore method pair is not
> protected by a transaction boundary for the methods that execute
> with an unspecified transaction con-text,
> the Bean Provider should not attempt to use the ejbLoad and
> ejbStore methods to control
> caching of the entity object�s state in the instance. Typically,
> the implementation of the ejbLoad and
> ejbStore methods should be a no-op (i.e. an empty method), and
> each business method should access
> the entity object�s state directly in the database.
> __________________________________________________________________
> ______________
>
> Evan Ireland Sybase EAServer Engineering
> [EMAIL PROTECTED]
> Wellington, New Zealand
> +64 4 934-5856
>
> ==================================================================
> =========
> 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".
