RE: [JBoss-user] JBoss 3.2.3 commit option B or C a lot slower than JBoss 3.2.1
If we didn't check any dirty flag you would not be able to update the data. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Boulatian, MisakSent: Saturday, January 17, 2004 2:38 AMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-user] JBoss 3.2.3 commit option B or C a lot slower than JBoss 3.2.1 There are some bugs in JBoss 3.2.1 that forced us move to 3.2.3. For example, in commit option C we would get warning 'unable to return to the pool due to ctx lock' every time that type of bean was being used. There was also another bug using version control attribute: cmp field could not be specified as a version control attribute that did not work with us. It seems like we cannot use JBoss 3.2.1 anymore because of these bugs so I cannot really prove if CMP 1.1 is faster than CMP 2.0 but I know that 'modified' flag helped us minimize database synchs. How is it done in CMP 2.0? From the traces I can tell that JBoss does not check any dirty flag. It seems like we are kind of stuck, don't know how to configure JBoss running with cluster. None of the options like cache invalidation with commit option A, regular cluster configuration, or even using commit option C without cluster with row level locking in DB,give us normal speed to go to production.
[JBoss-user] JBoss 3.2.3 commit option B or C a lot slower than JBoss 3.2.1
Hi, It seems like JBoss 3.2.3 commit option B or C a lot slower than JBoss 3.2.1 with same commit options. The only difference is that with JBoss 3.2.1 we were running CMP 1.1 with 'modified' flag optimization to minimize the number of synchronizations with Database (it served as some kind of dirty bit for an instance of entity bean). With JBoss 3.2.3 we moved to CMP 2.0 and lost the option to use 'modified' optimization. Can this be the source of slowdown? By the way, all my get methods are declared to be read only in the jboss.xml. Here is a piece of log that I got: - JBOSS 3.2.3 with Commit-Option B (Sybase row-level locking) I am doing a findBy***() to retrieve a Collection of references to an Entity Bean. While iterating through the collection, it appears that a SELECT statement is executed for every get() method that is called.In addition, the response time of each SELECT statement is ~300ms. How can I improve this performance? The Entity Bean is configured for transaction "Required". See logs below: 2004-01-16 08:45:22,706 136813 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.PositionDetail#findByAccountId] (TP-Processor4:) Executing SQL: SELECT t0_o.accountId, t0_o.accountType, t0_o.countryCode, t0_o.currency, t0_o.symbol, t0_o.symbolType FROM PositionDetail t0_o WHERE (t0_o.accountId = ?) 2004-01-16 08:45:22,706 136813 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) supplying ManagedConnection from pool: [EMAIL PROTECTED] 2004-01-16 08:45:22,706 136813 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Getting connection from pool [InUse/Available/Max]: [1/10/20] 2004-01-16 08:45:23,096 137203 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) putting ManagedConnection back into pool 2004-01-16 08:45:23,096 137203 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Returning connection to pool [InUse/Available/Max]: [0/10/20] 2004-01-16 08:45:23,096 137203 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.PositionDetail] (TP-Processor4:) Executing SQL: SELECT dayTradingAmount, dayTradingQuantity, marketValue, nonNegPosition, oca, requiredBoxQuantity, safekeepingQuantity, settlementDatePosition, tradeDatePosition, transferQuantity FROM PositionDetail WHERE (accountId=? AND accountType=? AND countryCode=? AND currency=? AND symbol=? AND symbolType=?) 2004-01-16 08:45:23,096 137203 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) supplying ManagedConnection from pool: [EMAIL PROTECTED] 2004-01-16 08:45:23,096 137203 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Getting connection from pool [InUse/Available/Max]: [1/10/20] 2004-01-16 08:45:23,300 137407 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) putting ManagedConnection back into pool 2004-01-16 08:45:23,300 137407 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Returning connection to pool [InUse/Available/Max]: [0/10/20] 2004-01-16 08:45:23,300 137407 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.PositionDetail] (TP-Processor4:) Executing SQL: SELECT dayTradingAmount, dayTradingQuantity, marketValue, nonNegPosition, oca, requiredBoxQuantity, safekeepingQuantity, settlementDatePosition, tradeDatePosition, transferQuantity FROM PositionDetail WHERE (accountId=? AND accountType=? AND countryCode=? AND currency=? AND symbol=? AND symbolType=?) 2004-01-16 08:45:23,300 137407 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) supplying ManagedConnection from pool: [EMAIL PROTECTED] 2004-01-16 08:45:23,300 137407 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Getting connection from pool [InUse/Available/Max]: [1/10/20] 2004-01-16 08:45:23,628 137735 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) putting ManagedConnection back into pool 2004-01-16 08:45:23,628 137735 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Returning connection to pool [InUse/Available/Max]: [0/10/20] 2004-01-16 08:45:23,628 137735 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.PositionDetail] (TP-Processor4:) Executing SQL: SELECT dayTradingAmount, dayTradingQuantity, marketValue, nonNegPosition, oca, requiredBoxQuantity, safekeepingQuantity, settlementDatePosition, tradeDatePosition, transferQuantity FROM PositionDetail WHERE (accountId=? AND accountType=? AND countryCode=? AND currency=? AND symbol=? AND symbolType=?) 2004-01-16 08:45:23,628 137735 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) supplying ManagedConnection from pool: [EMAIL
RE: [JBoss-user] JBoss 3.2.3 commit option B or C a lot slower than JBoss 3.2.1
Why don't you try to run CMP2.0 version of your app on 3.2.1 and see whether it's true. What your experience shows is that CMP1.1 app is faster than CMP2.0. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Boulatian, MisakSent: Friday, January 16, 2004 10:22 PMTo: [EMAIL PROTECTED]Subject: [JBoss-user] JBoss 3.2.3 commit option B or C a lot slower than JBoss 3.2.1 Hi, It seems like JBoss 3.2.3 commit option B or C a lot slower than JBoss 3.2.1 with same commit options. The only difference is that with JBoss 3.2.1 we were running CMP 1.1 with 'modified' flag optimization to minimize the number of synchronizations with Database (it served as some kind of dirty bit for an instance of entity bean). With JBoss 3.2.3 we moved to CMP 2.0 and lost the option to use 'modified' optimization. Can this be the source of slowdown? By the way, all my get methods are declared to be read only in the jboss.xml. Here is a piece of log that I got: - JBOSS 3.2.3 with Commit-Option B (Sybase row-level locking) I am doing a findBy***() to retrieve a Collection of references to an Entity Bean. While iterating through the collection, it appears that a SELECT statement is executed for every get() method that is called.In addition, the response time of each SELECT statement is ~300ms. How can I improve this performance? The Entity Bean is configured for transaction "Required". See logs below: 2004-01-16 08:45:22,706 136813 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.PositionDetail#findByAccountId] (TP-Processor4:) Executing SQL: SELECT t0_o.accountId, t0_o.accountType, t0_o.countryCode, t0_o.currency, t0_o.symbol, t0_o.symbolType FROM PositionDetail t0_o WHERE (t0_o.accountId = ?) 2004-01-16 08:45:22,706 136813 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) supplying ManagedConnection from pool: [EMAIL PROTECTED] 2004-01-16 08:45:22,706 136813 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Getting connection from pool [InUse/Available/Max]: [1/10/20] 2004-01-16 08:45:23,096 137203 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) putting ManagedConnection back into pool 2004-01-16 08:45:23,096 137203 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Returning connection to pool [InUse/Available/Max]: [0/10/20] 2004-01-16 08:45:23,096 137203 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.PositionDetail] (TP-Processor4:) Executing SQL: SELECT dayTradingAmount, dayTradingQuantity, marketValue, nonNegPosition, oca, requiredBoxQuantity, safekeepingQuantity, settlementDatePosition, tradeDatePosition, transferQuantity FROM PositionDetail WHERE (accountId=? AND accountType=? AND countryCode=? AND currency=? AND symbol=? AND symbolType=?) 2004-01-16 08:45:23,096 137203 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) supplying ManagedConnection from pool: [EMAIL PROTECTED] 2004-01-16 08:45:23,096 137203 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Getting connection from pool [InUse/Available/Max]: [1/10/20] 2004-01-16 08:45:23,300 137407 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) putting ManagedConnection back into pool 2004-01-16 08:45:23,300 137407 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Returning connection to pool [InUse/Available/Max]: [0/10/20] 2004-01-16 08:45:23,300 137407 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.PositionDetail] (TP-Processor4:) Executing SQL: SELECT dayTradingAmount, dayTradingQuantity, marketValue, nonNegPosition, oca, requiredBoxQuantity, safekeepingQuantity, settlementDatePosition, tradeDatePosition, transferQuantity FROM PositionDetail WHERE (accountId=? AND accountType=? AND countryCode=? AND currency=? AND symbol=? AND symbolType=?) 2004-01-16 08:45:23,300 137407 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) supplying ManagedConnection from pool: [EMAIL PROTECTED] 2004-01-16 08:45:23,300 137407 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Getting connection from pool [InUse/Available/Max]: [1/10/20] 2004-01-16 08:45:23,628 137735 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) putting ManagedConnection back into pool 2004-01-16 08:45:23,628 137735 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Returning connection to pool [InUse/Available/Max]: [0/10/20] 2004-01-16 08:45:23,
RE: [JBoss-user] JBoss 3.2.3 commit option B or C a lot slower than JBoss 3.2.1
There are some bugs in JBoss 3.2.1 that forced us move to 3.2.3. For example, in commit option C we would get warning 'unable to return to the pool due to ctx lock' every time that type of bean was being used. There was also another bug using version control attribute: cmp field could not be specified as a version control attribute that did not work with us. It seems like we cannot use JBoss 3.2.1 anymore because of these bugs so I cannot really prove if CMP 1.1 is faster than CMP 2.0 but I know that 'modified' flag helped us minimize database synchs. How is it done in CMP 2.0? From the traces I can tell that JBoss does not check any dirty flag. It seems like we are kind of stuck, don't know how to configure JBoss running with cluster. None of the options like cache invalidation with commit option A, regular cluster configuration, or even using commit option C without cluster with row level locking in DB, give us normal speed to go to production. -Original Message- From: Alexey Loubyansky [mailto:[EMAIL PROTECTED] Sent: Friday, January 16, 2004 3:07 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] JBoss 3.2.3 commit option B or C a lot slower than JBoss 3.2.1 Why don't you try to run CMP2.0 version of your app on 3.2.1 and see whether it's true. What your experience shows is that CMP1.1 app is faster than CMP2.0. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Boulatian, Misak Sent: Friday, January 16, 2004 10:22 PM To: [EMAIL PROTECTED] Subject: [JBoss-user] JBoss 3.2.3 commit option B or C a lot slower than JBoss 3.2.1 Hi, It seems like JBoss 3.2.3 commit option B or C a lot slower than JBoss 3.2.1 with same commit options. The only difference is that with JBoss 3.2.1 we were running CMP 1.1 with 'modified' flag optimization to minimize the number of synchronizations with Database (it served as some kind of dirty bit for an instance of entity bean). With JBoss 3.2.3 we moved to CMP 2.0 and lost the option to use 'modified' optimization. Can this be the source of slowdown? By the way, all my get methods are declared to be read only in the jboss.xml. Here is a piece of log that I got: - JBOSS 3.2.3 with Commit-Option B (Sybase row-level locking) I am doing a findBy***() to retrieve a Collection of references to an Entity Bean. While iterating through the collection, it appears that a SELECT statement is executed for every get() method that is called.In addition, the response time of each SELECT statement is ~300ms. How can I improve this performance? The Entity Bean is configured for transaction Required. See logs below: 2004-01-16 08:45:22,706 136813 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.PositionDetail#findByAccountI d] (TP-Processor4:) Executing SQL: SELECT t0_o.accountId, t0_o.accountType, t0_o.countryCode, t0_o.currency, t0_o.symbol, t0_o.symbolType FROM PositionDetail t0_o WHERE (t0_o.accountId = ?) 2004-01-16 08:45:22,706 136813 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) supplying ManagedConnection from pool: [EMAIL PROTECTED] 2004-01-16 08:45:22,706 136813 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Getting connection from pool [InUse/Available/Max]: [1/10/20] 2004-01-16 08:45:23,096 137203 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) putting ManagedConnection back into pool 2004-01-16 08:45:23,096 137203 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Returning connection to pool [InUse/Available/Max]: [0/10/20] 2004-01-16 08:45:23,096 137203 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.PositionDetail] (TP-Processor4:) Executing SQL: SELECT dayTradingAmount, dayTradingQuantity, marketValue, nonNegPosition, oca, requiredBoxQuantity, safekeepingQuantity, settlementDatePosition, tradeDatePosition, transferQuantity FROM PositionDetail WHERE (accountId=? AND accountType=? AND countryCode=? AND currency=? AND symbol=? AND symbolType=?) 2004-01-16 08:45:23,096 137203 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) supplying ManagedConnection from pool: [EMAIL PROTECTED] 2004-01-16 08:45:23,096 137203 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Getting connection from pool [InUse/Available/Max]: [1/10/20] 2004-01-16 08:45:23,300 137407 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) putting ManagedConnection back into pool 2004-01-16 08:45:23,300 137407 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Returning connection to pool [InUse/Available/Max]: [0/10/20] 2004-01-16 08:45:23,300 137407 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.PositionDetail] (TP-Processor4:) Executing SQL: SELECT dayTradingAmount, dayTradingQuantity, marketValue, nonNegPosition, oca
RE: [JBoss-user] JBoss 3.2.3 commit option B or C a lot slower than JBoss 3.2.1
Maybe this will give you a hint: http://www.mail-archive.com/[EMAIL PROTECTED]/msg34183.html read-only means doesn't synchronize with the transaction option C says don't cache between transactions This means the bean is removed from cache after each read-only invocation unless the lock has been promoted a transactional lock by a non read-only invocation. In other words, the data is reloaded on each invocation. Regards, Adrian On Sat, 2004-01-17 at 00:37, Boulatian, Misak wrote: There are some bugs in JBoss 3.2.1 that forced us move to 3.2.3. For example, in commit option C we would get warning 'unable to return to the pool due to ctx lock' every time that type of bean was being used. There was also another bug using version control attribute: cmp field could not be specified as a version control attribute that did not work with us. It seems like we cannot use JBoss 3.2.1 anymore because of these bugs so I cannot really prove if CMP 1.1 is faster than CMP 2.0 but I know that 'modified' flag helped us minimize database synchs. How is it done in CMP 2.0? From the traces I can tell that JBoss does not check any dirty flag. It seems like we are kind of stuck, don't know how to configure JBoss running with cluster. None of the options like cache invalidation with commit option A, regular cluster configuration, or even using commit option C without cluster with row level locking in DB, give us normal speed to go to production. -Original Message- From: Alexey Loubyansky [mailto:[EMAIL PROTECTED] Sent: Friday, January 16, 2004 3:07 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] JBoss 3.2.3 commit option B or C a lot slower than JBoss 3.2.1 Why don't you try to run CMP2.0 version of your app on 3.2.1 and see whether it's true. What your experience shows is that CMP1.1 app is faster than CMP2.0. __ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Boulatian, Misak Sent: Friday, January 16, 2004 10:22 PM To: [EMAIL PROTECTED] Subject: [JBoss-user] JBoss 3.2.3 commit option B or C a lot slower than JBoss 3.2.1 Hi, It seems like JBoss 3.2.3 commit option B or C a lot slower than JBoss 3.2.1 with same commit options. The only difference is that with JBoss 3.2.1 we were running CMP 1.1 with 'modified' flag optimization to minimize the number of synchronizations with Database (it served as some kind of dirty bit for an instance of entity bean). With JBoss 3.2.3 we moved to CMP 2.0 and lost the option to use 'modified' optimization. Can this be the source of slowdown? By the way, all my get methods are declared to be read only in the jboss.xml. Here is a piece of log that I got: - JBOSS 3.2.3 with Commit-Option B (Sybase row-level locking) I am doing a findBy***() to retrieve a Collection of references to an Entity Bean. While iterating through the collection, it appears that a SELECT statement is executed for every get() method that is called.In addition, the response time of each SELECT statement is ~300ms. How can I improve this performance? The Entity Bean is configured for transaction Required. See logs below: 2004-01-16 08:45:22,706 136813 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.PositionDetail#findByAccountId] (TP-Processor4:) Executing SQL: SELECT t0_o.accountId, t0_o.accountType, t0_o.countryCode, t0_o.currency, t0_o.symbol, t0_o.symbolType FROM PositionDetail t0_o WHERE (t0_o.accountId = ?) 2004-01-16 08:45:22,706 136813 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) supplying ManagedConnection from pool: [EMAIL PROTECTED] 2004-01-16 08:45:22,706 136813 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) Getting connection from pool [InUse/Available/Max]: [1/10/20] 2004-01-16 08:45:23,096 137203 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (TP-Processor4:) putting ManagedConnection back into pool 2004-01-16 08:45:23,096 137203 TRACE
