Since the EJB spec leaves the handling of how ejbLoad() and ejbStore() are
called up to the container developer(jBoss), (the spec is very loose), I was
wondering how jBoss handles this and maybe someone can give me some useful
insights.
Below is a cut and past from the ejb spec.(Take note of note [7] in the text
i.e. 'unreliable' transaction contexts also apply to the Never and Supports
attribute.)
My question is, if Never is also an 'unreliable' transaction context, how
does one implement a read-only bean managed entity bean i.e. I DON'T WANT
a bunch of 'read-only' beans doing ejbStore() outside a transaction boundary
screwing up valid data. The suggestion in the text
is that ejbStore be an empty method and that the business methods call some
other method to do the storing. This just seems plain ugly. Why use EJB if I
have to go through all this hassle?
I quess what I would like to see is that ejbStore() be called ONLY if at
least one remote requires, mandatory, requires new method is called on the
bean.
Any comments, what am I missing here, how does jBoss handle 'unreliable'
transaction contexts? (It appears to ejbStore() as often as possible)
Thanks in advance.
Andrew
Concepts Enterprise JavaBeans v1.1, Final Release Entity Bean Component
Contract
113 11/24/99
Sun Microsystem Inc
entity state. The ejbStore method writes the updated parts of the entity
object's state to the
database.
. An instance loads the most frequently used part of the entity object's
state in the ejbLoad
method and caches it until the container invokes the ejbStore method.
Additional parts of
the entity object's state are loaded as needed by the business methods. The
ejbStore method
writes the updated parts of the entity object's state to the database.
. An instance does not cache any entity object's state between business
methods. The business
methods access and modify the entity object's state directly in the
database. The ejbLoad
and ejbStore methods have an empty implementation.
We expect that most entity developers will not manually code the cache
management and data access
calls in the entity bean class. We expect that they will rely on application
development tools to provide
various data access components that encapsulate data access and provide
state caching.
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.
[7] This applies also to the Never and Supports attribute.
> -----Original Message-----
> From: Andy Riedel [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 10, 2001 11:55 PM
> To: jBoss
> Subject: RE: CRITICAL BUG: RE: [jBoss-User] Transactions - Spurious
> ejbStore -AAAAGGGHHH
>
>
> Cool, thanks for the clarification Tobias!
>
> Andy
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Tobias Frech
> Sent: Wednesday, January 10, 2001 4:36 PM
> To: jBoss
> Subject: Re: CRITICAL BUG: RE: [jBoss-User] Transactions - Spurious
> ejbStore -AAAAGGGHHH
>
>
> Hi guys!
> JBoss 2.0-FINAL was released around Nov. 19, 2000. The patch you
> described was committed to the cvs by Sebastien Alborini at Nov. 29,
> 2000. Clearly JBoss 2.0-FINAL does not have it but the actual cvs
> version does.
> If you need JBoss 2.0-FINAL with that patch, use cvs to checkout an
> older version and apply the patch yourself. If there are any problems
> with that just tell me and you'll receive a zip from me.
>
> Cheers,
> Tobias
>
> Andy Riedel wrote:
> >
> > Hi Andrew,
> >
> > I discovered a bug in the way method transactions are handled in
> > org.jboss.BeanMetaData which I reported but apparently
> didn't make it into
> > the jBoss2.0 final release. I reported it to the author
> Sebastien Alborini
> > ([EMAIL PROTECTED]) but I'm not certain if the fix was ever
> > applied. Perhaps Sebastien can clarify the situation.
> >
> > The bug is in the getMethodTransactionType method. The
> current version
> > always matches a method to the '*' definition in the
> ejb-jar.xml even if
> the
> > method is explicitly overriden with its own definition later on. The
> patched
> > version of this method we are using is shown below:
> >
> > public byte getMethodTransactionType(String
> methodName, Class[]
> params,
> > boolean remote) {
> > byte result = TX_UNKNOWN;
> >
> > Iterator iterator = getTransactionMethods();
> > while (iterator.hasNext()) {
> > MethodMetaData m =
> (MethodMetaData)iterator.next();
> > if (m.patternMatches(methodName,
> params, remote))
> {
> > result = m.getTransactionType();
> > if (!m.getMethodName().equals("*")) {
> > break;
> > }
> > }
> > }
> >
> > // System.out.println("Trans type for:
> > "+methodName+"="+result);
> > return result;
> > }
> >
> > This version ensures that all method definitions are iterated before
> > breaking out of its processing loop.
> >
> > This may be your problem since your "overridden" transaction method
> > definitions are always matched to the '*' definition.
> >
> > Andy Riedel
> > XadrA LLC
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Nortje, Andrew
> > Sent: Wednesday, January 10, 2001 3:24 PM
> > To: 'jBoss'
> > Subject: [jBoss-User] Transactions - Spurious ejbStore - AAAAGGGHHH
> >
> > Folks at jBoss
> >
> > I am having real trouble with jBoss transactions and 'spurious'
> ejbStore().
> >
> > I have an Account entity bean that has a balance that must
> be updated. I
> > noticed in by debug statements that a set of Account's,
> which were under
> the
> > control of a single transaction, were been updated correcty
> until the very
> > last step. What happens is the following:
> >
> > Somewhere in my code I create an instance of an Account
> bean which I only
> > use for "read only" (to get the account number and
> balance). ejbStore() is
> > however being called on this bean, even though no
> transaction REQUIRED
> > methods are ever called on this "read only" instance of the
> Account bean.
> > The correct balance in the database is then over written.
> >
> > I then went into ejb-jar.xml and made sure that all bean
> remote and home
> > interfaces, using * wildcard, (hence all methods in all beans ) were
> marked
> > as NOT SUPPRORTING transactions. I then went and
> selectively set a few
> > methods ( account.updateBalance() for one ) to REQUIRED.
> jBoss now hangs
> > somewhere on the transaction even though jBoss seems to
> still be working
> (I
> > see passivation of overaged bean messages etc). My client also hangs
> waiting
> > for a reply from jBoss. No exceptions thrown anywhere. When
> I try stop
> jBoss
> > using ^C it then really hangs and I have to kill it.
> >
> > I am using the this pointer to figure out which instance of
> bean is being
> > called when. No REQUIRED transaction methods are ever
> called on the 'read
> > only' instance on the Account bean but ejbStore is.
> >
> > What to do?
> >
> > (I am using jBoss-2.0_FINAL.zip (4.19M) on Win 2000 (
> Production is on
> Linux
> > ))
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > List Help?: [EMAIL PROTECTED]
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > List Help?: [EMAIL PROTECTED]
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> List Help?: [EMAIL PROTECTED]
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> List Help?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
