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]
