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".
