RE: [JBoss-dev] RE: how's ecperf going?
Agreed. In this case there is a strong performance reason to split the code into two interceptors: The point is that the call in the interceptors is JUST dissaciation and association. The mumbo jumbo we are talking about (whatever it means to suspend and resume a transaction) is not really relevant to the interceptor. I don't think we need to change the interceptor just the fact that suspend/resume should not be distributed calls just association calls in JTA. Let's treat spec bugs for what they are. BUGS. marcf client tx interceptor attaches the tx to the invocation only if the tx is going to be used (requires, supports and there is a tx). For requires new it removes the tx if attached [ (for remote invoker only) invoker xaresource converts tx if it exists into an xid -transport --- xid is used to start/identify tx on other jboss instance ONLY IF PRESENT ] server tx interceptor creates new tx if required and not present. Now each interceptor is very clear about its responsiblitly. Furthermore, the tx is NOTimported into the 2nd jboss vm if it can be determined that it won't be doing any work there. This saves one or two remote calls during commit. david -dain On Monday, January 27, 2003, at 05:40 PM, David Jencks wrote: FWIW, I agree 100% with you on this marc david jencks On Monday, January 27, 2003, at 05:34 PM, marc fleury wrote: In all of the other application servers I have been working on TransactionManager.resume() and suspend() are expensive operations, since the JTA spec version 1.0.1 (section 3.2.3) requires the TM to delist/enlist every resource that takes part in the transaction, which is costly. If it is done differently in Jboss on purpose, IT IS A BUG IN THE SPEC ! I am dead serious. Also all the discussion sucks and comes from the name of the API. Suspend() and resume() look like they are Tx lifecycle operations which require resource delisting??? NO NO NO, resume and suspend in the scope of what we do in the method is PURELY THREAD ASSOCIATION, the TX goes on. In our code it means resume association suspend association not suspend TX. I had called it dissassociateThread() and associateThread() to emph the fact that all we are looking for is association of thread to TX and THAT'S IT. It was changed in subsequent impls. You are talking about something else, you are talking about the notion of suspending THE TRANSACTION. Do we have a line? marcf Doesn't anyone else see this? I feel like I am taking crazy pills -- ZooLander -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: how's ecperf going?
On Tuesday, January 28, 2003, at 10:07 AM, marc fleury wrote: Agreed. In this case there is a strong performance reason to split the code into two interceptors: The point is that the call in the interceptors is JUST dissaciation and association. The mumbo jumbo we are talking about (whatever it means to suspend and resume a transaction) is not really relevant to the interceptor. I don't think we need to change the interceptor just the fact that suspend/resume should not be distributed calls just association calls in JTA. Let's treat spec bugs for what they are. We already agreed with you that in one vm association/dissociation are essentially free and if they aren't it is a bug. I'm saying that importing a tx when you don't need to is NOT free and if we avoid it the code will become easier to understand. Although easy to understand is definitely subjective I have also found myself confused by the current code in the server side tx interceptor. david BUGS. marcf client tx interceptor attaches the tx to the invocation only if the tx is going to be used (requires, supports and there is a tx). For requires new it removes the tx if attached [ (for remote invoker only) invoker xaresource converts tx if it exists into an xid -transport --- xid is used to start/identify tx on other jboss instance ONLY IF PRESENT ] server tx interceptor creates new tx if required and not present. Now each interceptor is very clear about its responsiblitly. Furthermore, the tx is NOTimported into the 2nd jboss vm if it can be determined that it won't be doing any work there. This saves one or two remote calls during commit. david -dain On Monday, January 27, 2003, at 05:40 PM, David Jencks wrote: FWIW, I agree 100% with you on this marc david jencks On Monday, January 27, 2003, at 05:34 PM, marc fleury wrote: In all of the other application servers I have been working on TransactionManager.resume() and suspend() are expensive operations, since the JTA spec version 1.0.1 (section 3.2.3) requires the TM to delist/enlist every resource that takes part in the transaction, which is costly. If it is done differently in Jboss on purpose, IT IS A BUG IN THE SPEC ! I am dead serious. Also all the discussion sucks and comes from the name of the API. Suspend() and resume() look like they are Tx lifecycle operations which require resource delisting??? NO NO NO, resume and suspend in the scope of what we do in the method is PURELY THREAD ASSOCIATION, the TX goes on. In our code it means resume association suspend association not suspend TX. I had called it dissassociateThread() and associateThread() to emph the fact that all we are looking for is association of thread to TX and THAT'S IT. It was changed in subsequent impls. You are talking about something else, you are talking about the notion of suspending THE TRANSACTION. Do we have a line? marcf Doesn't anyone else see this? I feel like I am taking crazy pills -- ZooLander -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com
Re: [JBoss-dev] RE: how's ecperf going?
On Tuesday, January 28, 2003, at 09:07 AM, marc fleury wrote: Agreed. In this case there is a strong performance reason to split the code into two interceptors: The point is that the call in the interceptors is JUST dissaciation and association. The mumbo jumbo we are talking about (whatever it means to suspend and resume a transaction) is not really relevant to the interceptor. I don't think we need to change the interceptor just the fact that suspend/resume should not be distributed calls just association calls in JTA. Let's treat spec bugs for what they are. BUGS. That sounds logical, but we don't get to change the specs. This would be like Scott saying that classloading works perfectly, but the Sun JVM has a bug (which is does); in the end he coded around the problem. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: how's ecperf going?
We already agreed with you that in one vm association/dissociation are essentially free and if they aren't it is a bug. I'm saying that oh ok :) sorry jumpy. yes association dissociation should be clearly exposed JTA calls. Spec bug. importing a tx when you don't need to is NOT free clearly. clearly. marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: how's ecperf going?
* TxInterceptorCMP suspends and resumes a transaction in all cases, sometimes even twice. This can be very expensive, especially with global transactions. ?? Can you point this out? for the nth time we are having this discussion. NO, the 'suspend/resume' is NOT A LIFECYCLE EVEN ON THE TRANSACTION. That says that there is no distribution of that event. S/R just says that we DIS-ASSOCIATE the thread from the transaction and that's it. If a TM implements notifications of this, it is A BUG. marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: how's ecperf going?
yes, if you take a look at the code, before the switch statement that distinguishes the cases between the different transaction attributes, we start by a tx.suspend() and, a few lines after, a tx.resume() if it was a REQUIRES tag for example, etc. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de marc fleury Envoye : lundi, 27 janvier 2003 16:52 A : [EMAIL PROTECTED]; 'Stefan Reich' Objet : RE: [JBoss-dev] RE: how's ecperf going? * TxInterceptorCMP suspends and resumes a transaction in all cases, sometimes even twice. This can be very expensive, especially with global transactions. ?? Can you point this out? for the nth time we are having this discussion. NO, the 'suspend/resume' is NOT A LIFECYCLE EVEN ON THE TRANSACTION. That says that there is no distribution of that event. S/R just says that we DIS-ASSOCIATE the thread from the transaction and that's it. If a TM implements notifications of this, it is A BUG. marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: how's ecperf going?
yes, if you take a look at the code, before the switch statement that distinguishes the cases between the different transaction attributes, we start by a tx.suspend() and, a few lines after, a tx.resume() if it was a REQUIRES tag for example, etc. I know I wrote the original version of the code. What I argued Nth times is that tx.suspend() should just be implemented with threadLocalVariable.set(null); meaning that we disassociate the thread from the TX. The event thread dis-association is not relevant to anyone else, not even to the TX. The TX DOESN'T CARE that it is associated with n threads or not. Man I really need to write that TX-lite spec. It is a fucking mess in your heads right now :) marcf -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de marc fleury Envoye : lundi, 27 janvier 2003 16:52 A : [EMAIL PROTECTED]; 'Stefan Reich' Objet : RE: [JBoss-dev] RE: how's ecperf going? * TxInterceptorCMP suspends and resumes a transaction in all cases, sometimes even twice. This can be very expensive, especially with global transactions. ?? Can you point this out? for the nth time we are having this discussion. NO, the 'suspend/resume' is NOT A LIFECYCLE EVEN ON THE TRANSACTION. That says that there is no distribution of that event. S/R just says that we DIS-ASSOCIATE the thread from the transaction and that's it. If a TM implements notifications of this, it is A BUG. marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: how's ecperf going?
I am all for it. The more people run Ecperf on various platforms and JDKs, the better for the quality. Stefan Message: 6 From: Sacha Labourey [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Re: how's ecperf going? Date: Sat, 25 Jan 2003 11:45:58 +0100 Reply-To: [EMAIL PROTECTED] BTW, that's a cool idea: we should have not only the testsuite running on different JVM/OS but the ECPERF to see the evolution of performance accross releases (so we would need some kind of result page where each day we have a different value). NetBeans has this. I could set it up to run on Windows Advanced Server bi-proc if you want. I was setting up some automated clustering testing before the training but had issues with build/build.xml calling testsuite/build.xml (bug in buildmagic probably) I wrote to Jason but I guess he has other priorities (such as looking at the blue sky) -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Stefan Reich Envoye : samedi, 25 janvier 2003 02:24 A : [EMAIL PROTECTED] Cc : [EMAIL PROTECTED] Objet : [JBoss-dev] Re: how's ecperf going? Hi Bill, I am running ecperf regularly on the 3.0 and 3.2 branches. I accumulated a bunch of fixes for scalability and performance problems already, plus a few fixes for inconsistent lock usage that I will merge soon. Here are some things I noticed: * the test fails when I deploy the BMP version, some of the beans that have been created don't seem to end up in the database. * the CMP version must be tweaked to use the util.xml BMP version of the beans (search for SERIALIZABLE in the README) to work correctly * the CMP version doesn't deploy anymore on the current 3.2 branch * with the 3.2 branch I get many more spurious esceptions than with 3.0 * a HashMap in the class CachedConnectionManager seems to be the most contended lock * JAWS checks for the existence of a PK before inserting a new row in the database. This is pretty expensive. * the LogInterceptor usage of the NDC class makes it a global source of contention * TxInterceptorCMP suspends and resumes a transaction in all cases, sometimes even twice. This can be very expensive, especially with global transactions. Since I am running the tests on PowerPC Macs and the Apple VM it is hard to compare the results with other platforms. Stefan On Thursday, Jan 23, 2003, at 19:11 US/Pacific, Bill Burke wrote: Are you getting decent results? I heard from Scott that you've made some improvements. Need me to merge your changes at all? Just want to know what's up. Thanks, Bill Burke Chief Architect JBoss Group, LLC --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: how's ecperf going?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Monday, January 27, 2003 11:17 AM To: [EMAIL PROTECTED]; 'Stefan Reich' Subject: RE: [JBoss-dev] RE: how's ecperf going? yes, if you take a look at the code, before the switch statement that distinguishes the cases between the different transaction attributes, we start by a tx.suspend() and, a few lines after, a tx.resume() if it was a REQUIRES tag for example, etc. I know I wrote the original version of the code. What I argued Nth times is that tx.suspend() should just be implemented with threadLocalVariable.set(null); meaning that we disassociate the thread from the TX. The event thread dis-association is not relevant to anyone else, not even to the TX. The TX DOESN'T CARE that it is associated with n threads or not. Actually it MUST care. The TX needs to interrupt threads on a TX timeout. But you're right about the performance irrelevance. There's nothing really expensive going on, nor should there be. Bill --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: how's ecperf going?
In all of the other application servers I have been working on TransactionManager.resume() and suspend() are expensive operations, since the JTA spec version 1.0.1 (section 3.2.3) requires the TM to delist/enlist every resource that takes part in the transaction, which is costly. If it is done differently in Jboss on purpose, that's fine, I just wanted to make sure it's no oversight. Stefan On Monday, Jan 27, 2003, at 13:08 US/Pacific, Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Monday, January 27, 2003 11:17 AM To: [EMAIL PROTECTED]; 'Stefan Reich' Subject: RE: [JBoss-dev] RE: how's ecperf going? yes, if you take a look at the code, before the switch statement that distinguishes the cases between the different transaction attributes, we start by a tx.suspend() and, a few lines after, a tx.resume() if it was a REQUIRES tag for example, etc. I know I wrote the original version of the code. What I argued Nth times is that tx.suspend() should just be implemented with threadLocalVariable.set(null); meaning that we disassociate the thread from the TX. The event thread dis-association is not relevant to anyone else, not even to the TX. The TX DOESN'T CARE that it is associated with n threads or not. Actually it MUST care. The TX needs to interrupt threads on a TX timeout. But you're right about the performance irrelevance. There's nothing really expensive going on, nor should there be. Bill --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: how's ecperf going?
In all of the other application servers I have been working on TransactionManager.resume() and suspend() are expensive operations, since the JTA spec version 1.0.1 (section 3.2.3) requires the TM to delist/enlist every resource that takes part in the transaction, which is costly. If it is done differently in Jboss on purpose, IT IS A BUG IN THE SPEC ! I am dead serious. Also all the discussion sucks and comes from the name of the API. Suspend() and resume() look like they are Tx lifecycle operations which require resource delisting??? NO NO NO, resume and suspend in the scope of what we do in the method is PURELY THREAD ASSOCIATION, the TX goes on. In our code it means resume association suspend association not suspend TX. I had called it dissassociateThread() and associateThread() to emph the fact that all we are looking for is association of thread to TX and THAT'S IT. It was changed in subsequent impls. You are talking about something else, you are talking about the notion of suspending THE TRANSACTION. Do we have a line? marcf Doesn't anyone else see this? I feel like I am taking crazy pills -- ZooLander -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: how's ecperf going?
FWIW, I agree 100% with you on this marc david jencks On Monday, January 27, 2003, at 05:34 PM, marc fleury wrote: In all of the other application servers I have been working on TransactionManager.resume() and suspend() are expensive operations, since the JTA spec version 1.0.1 (section 3.2.3) requires the TM to delist/enlist every resource that takes part in the transaction, which is costly. If it is done differently in Jboss on purpose, IT IS A BUG IN THE SPEC ! I am dead serious. Also all the discussion sucks and comes from the name of the API. Suspend() and resume() look like they are Tx lifecycle operations which require resource delisting??? NO NO NO, resume and suspend in the scope of what we do in the method is PURELY THREAD ASSOCIATION, the TX goes on. In our code it means resume association suspend association not suspend TX. I had called it dissassociateThread() and associateThread() to emph the fact that all we are looking for is association of thread to TX and THAT'S IT. It was changed in subsequent impls. You are talking about something else, you are talking about the notion of suspending THE TRANSACTION. Do we have a line? marcf Doesn't anyone else see this? I feel like I am taking crazy pills -- ZooLander -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: how's ecperf going?
I completely agree that the extra suspend/ resume should not cause any performance degradation. The problem with that code it is fucking hard to read. Your stare at it for a while going what the fuck is he doing here and then you finally realize that they always suspend the tx at the beginning of the method. This code is much easier to read if you put an if/else in the outer most element and only touch the transaction if you have to. I made this change when messing around but never got to committing it. Unless there is a real measurable performance problem I think we should always favor readability and maintainability of code. -dain On Monday, January 27, 2003, at 05:40 PM, David Jencks wrote: FWIW, I agree 100% with you on this marc david jencks On Monday, January 27, 2003, at 05:34 PM, marc fleury wrote: In all of the other application servers I have been working on TransactionManager.resume() and suspend() are expensive operations, since the JTA spec version 1.0.1 (section 3.2.3) requires the TM to delist/enlist every resource that takes part in the transaction, which is costly. If it is done differently in Jboss on purpose, IT IS A BUG IN THE SPEC ! I am dead serious. Also all the discussion sucks and comes from the name of the API. Suspend() and resume() look like they are Tx lifecycle operations which require resource delisting??? NO NO NO, resume and suspend in the scope of what we do in the method is PURELY THREAD ASSOCIATION, the TX goes on. In our code it means resume association suspend association not suspend TX. I had called it dissassociateThread() and associateThread() to emph the fact that all we are looking for is association of thread to TX and THAT'S IT. It was changed in subsequent impls. You are talking about something else, you are talking about the notion of suspending THE TRANSACTION. Do we have a line? marcf Doesn't anyone else see this? I feel like I am taking crazy pills -- ZooLander -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: how's ecperf going?
On Monday, January 27, 2003, at 08:03 PM, Dain Sundstrom wrote: I completely agree that the extra suspend/ resume should not cause any performance degradation. The problem with that code it is fucking hard to read. Your stare at it for a while going what the fuck is he doing here and then you finally realize that they always suspend the tx at the beginning of the method. This code is much easier to read if you put an if/else in the outer most element and only touch the transaction if you have to. I made this change when messing around but never got to committing it. Unless there is a real measurable performance problem I think we should always favor readability and maintainability of code. Agreed. In this case there is a strong performance reason to split the code into two interceptors: client tx interceptor attaches the tx to the invocation only if the tx is going to be used (requires, supports and there is a tx). For requires new it removes the tx if attached [ (for remote invoker only) invoker xaresource converts tx if it exists into an xid -transport --- xid is used to start/identify tx on other jboss instance ONLY IF PRESENT ] server tx interceptor creates new tx if required and not present. Now each interceptor is very clear about its responsiblitly. Furthermore, the tx is NOTimported into the 2nd jboss vm if it can be determined that it won't be doing any work there. This saves one or two remote calls during commit. david -dain On Monday, January 27, 2003, at 05:40 PM, David Jencks wrote: FWIW, I agree 100% with you on this marc david jencks On Monday, January 27, 2003, at 05:34 PM, marc fleury wrote: In all of the other application servers I have been working on TransactionManager.resume() and suspend() are expensive operations, since the JTA spec version 1.0.1 (section 3.2.3) requires the TM to delist/enlist every resource that takes part in the transaction, which is costly. If it is done differently in Jboss on purpose, IT IS A BUG IN THE SPEC ! I am dead serious. Also all the discussion sucks and comes from the name of the API. Suspend() and resume() look like they are Tx lifecycle operations which require resource delisting??? NO NO NO, resume and suspend in the scope of what we do in the method is PURELY THREAD ASSOCIATION, the TX goes on. In our code it means resume association suspend association not suspend TX. I had called it dissassociateThread() and associateThread() to emph the fact that all we are looking for is association of thread to TX and THAT'S IT. It was changed in subsequent impls. You are talking about something else, you are talking about the notion of suspending THE TRANSACTION. Do we have a line? marcf Doesn't anyone else see this? I feel like I am taking crazy pills -- ZooLander -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: how's ecperf going?
Thanks for the update. Can you let me know which hashmap in CachedConnectionManager is causing contention? Also, I have a plan for 4 anyway to only swap transactions when they actually change. it should be pretty easy to fix in 3/3.2 directly also. thanks david jencks On Friday, January 24, 2003, at 08:23 PM, Stefan Reich wrote: Hi Bill, I am running ecperf regularly on the 3.0 and 3.2 branches. I accumulated a bunch of fixes for scalability and performance problems already, plus a few fixes for inconsistent lock usage that I will merge soon. Here are some things I noticed: * the test fails when I deploy the BMP version, some of the beans that have been created don't seem to end up in the database. * the CMP version must be tweaked to use the util.xml BMP version of the beans (search for SERIALIZABLE in the README) to work correctly * the CMP version doesn't deploy anymore on the current 3.2 branch * with the 3.2 branch I get many more spurious esceptions than with 3.0 * a HashMap in the class CachedConnectionManager seems to be the most contended lock * JAWS checks for the existence of a PK before inserting a new row in the database. This is pretty expensive. * the LogInterceptor usage of the NDC class makes it a global source of contention * TxInterceptorCMP suspends and resumes a transaction in all cases, sometimes even twice. This can be very expensive, especially with global transactions. Since I am running the tests on PowerPC Macs and the Apple VM it is hard to compare the results with other platforms. Stefan On Thursday, Jan 23, 2003, at 19:11 US/Pacific, Bill Burke wrote: Are you getting decent results? I heard from Scott that you've made some improvements. Need me to merge your changes at all? Just want to know what's up. Thanks, Bill Burke Chief Architect JBoss Group, LLC --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
