OK everyone chill.
I don't remember how it is coded to be honest. So yes do look at the BMP
invocation chain if you can. If not ping me again in a couple of weeks when
I am through the current work.
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Nortje, Andrew
|Sent: Friday, January 12, 2001 10:12 AM
|To: 'jBoss'
|Subject: RE: [jBoss-User] jBoss ejbStore() for BMP
|
|
|How did you work that out?
|
|> -----Original Message-----
|> From: Kenworthy, Edward [mailto:[EMAIL PROTECTED]]
|> Sent: Friday, January 12, 2001 10:32 AM
|> To: 'jBoss'
|> Subject: RE: [jBoss-User] jBoss ejbStore() for BMP
|>
|>
|> If you're not prepared to help yourself why should anyone else ?
|>
|> -----Original Message-----
|> From: Nortje, Andrew [mailto:[EMAIL PROTECTED]]
|> Sent: 12 January 2001 15:08
|> To: 'jBoss'
|> Subject: RE: [jBoss-User] jBoss ejbStore() for BMP
|>
|>
|> nss - this is however the jBoss support forum, I have
|> researched before
|> asking the question, its specific, its relevant.
|>
|> Support is there to save us time digging through the code to find the
|> answers?
|>
|> BTW Cut and paste from the jBoss web site
|> ---
|> [EMAIL PROTECTED]
|> Is the main list for general discussion of jBoss, send
|> support questions
|> here as well.
|> ---
|>
|> > -----Original Message-----
|> > From: Kenworthy, Edward [mailto:[EMAIL PROTECTED]]
|> > Sent: Friday, January 12, 2001 9:56 AM
|> > To: 'jBoss'
|> > Subject: RE: [jBoss-User] jBoss ejbStore() for BMP
|> >
|> >
|> > It's open source so you could always go read the source.
|> >
|> > -----Original Message-----
|> > From: Nortje, Andrew [mailto:[EMAIL PROTECTED]]
|> > Sent: 12 January 2001 13:41
|> > To: 'jBoss'
|> > Subject: [jBoss-User] jBoss ejbStore() for BMP
|> >
|> >
|> > 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]
|> >
|> >
|> > --
|> > --------------------------------------------------------------
|> > 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]
