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]
