RE: [JBoss-user] JBoss clustering with commit option B or C too slow
Hi Alexey, With our application I cannot use commit option A with optimistic locking. It generates a lot of rollbacks (many threads access the same beans at the same times through message driven beans). I've tried to use commit option A with cache invalidation but performance was no better. Is there any other way to optimize commit option B or C? Thanks, Misak -Original Message- From: Alexey Loubyansky [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 7:32 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] JBoss clustering with commit option B or C too slow You could use commit option A with optimistic locking. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Boulatian, Misak Sent: Wednesday, January 14, 2004 7:48 PM To: [EMAIL PROTECTED] Subject: [JBoss-user] JBoss clustering with commit option B or C too slow Hi, I am trying to cluster JBoss 3.2.3 with CMP 2.0. Current clustering configuration doesn't allow me to use commit option A (Only with cache invalidation based clustering A can be used). So, I need to use commit option B or C. With CMP 1.1 there was a modified flag that allowed control over synchronization with Database. With CMP 2.0 the flag is of no use. I wonder if there is a way to improve performance with commit option B or C using CMP 2.0. It is terribly slow in a clustered environment. Is there any other way to cluster to improve performance.? Thanks, Misak This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. <>
RE: [JBoss-user] JBoss clustering with commit option B or C too slow
You could use commit option A with optimistic locking. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Boulatian, MisakSent: Wednesday, January 14, 2004 7:48 PMTo: [EMAIL PROTECTED]Subject: [JBoss-user] JBoss clustering with commit option B or C too slow Hi, I am trying to cluster JBoss 3.2.3 with CMP 2.0. Current clustering configuration doesn't allow me to use commit option A (Only with cache invalidation based clustering A can be used). So, I need to use commit option B or C. With CMP 1.1 there was a modified flag that allowed control over synchronization with Database. With CMP 2.0 the flag is of no use. I wonder if there is a way to improve performance with commit option B or C using CMP 2.0. It is terribly slow in a clustered environment. Is there any other way to cluster to improve performance.? Thanks, Misak This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
[JBoss-user] JBoss clustering with commit option B or C too slow
Hi, I am trying to cluster JBoss 3.2.3 with CMP 2.0. Current clustering configuration doesn't allow me to use commit option A (Only with cache invalidation based clustering A can be used). So, I need to use commit option B or C. With CMP 1.1 there was a modified flag that allowed control over synchronization with Database. With CMP 2.0 the flag is of no use. I wonder if there is a way to improve performance with commit option B or C using CMP 2.0. It is terribly slow in a clustered environment. Is there any other way to cluster to improve performance.? Thanks, Misak This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
