First thanks to all who have responded to my question. I will apply the patch and see what happens. While waiting for some replies I did some reading and saw the following... This is a cut and past from the ejb spec. Looks like this might be my problem. (Take note of note [7] in the text i.e. 'unreliable' transaction contexts apply also to the Never and Supports attribute.) My question is, if Never is also an 'unreliable' transaction context, how on earth does one implement a read-only bean managed entity bean - I DON'T WANT a bunch of 'read-only' beans screwing up my 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? Any comments, what am I missing here, how does jBoss handle 'unreliable' transaction contexts? 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]
