Hello Jos�, is the measured time the time actually needed for the SQL statement, i.e. do you measure the time before calling the execute method of the statement, and afterwards, and is there the difference?
Regards Alexander Schr�der SAP DB, SAP Labs Berlin > -----Original Message----- > From: Jos� R�mulo El�as Contreras > [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 15, 2005 4:54 PM > To: Schroeder, Alexander > Cc: Bodo.Teichmann; [email protected] > Subject: Re: AW: Release transaction??? > > Hi, > > I have the same problems that Bodo, during havy load of our > tomcat application. When no havy load it works well. > > Another question, I test the performance of SAPDB in > two tomcat > servers connecting to the same database. Each tomcat server open 10 > sessions with the next parameters: > > DriverManager.getConnection(databaseUrl + databaseName + "?user=" + > databaseUser + "&password=" + databasePassword + > "&timeout=0&isolation=" > + java.sql.Connection.TRANSACTION_READ_UNCOMMITTED); > > I open 4 differents browser sessions connected 2 to > each tomcat > server. If I request the same information in each different browser > session at the same time the performance go down. The first session > connected to tomcatServer1 takes 9 seconds to execute the query, the > second session connected to tomcatServer1 takes 12 seconds to execute > the query, the third session connected to tomcatServer2 takes > 14 seconds > to execute the query and the fourth session connected to > tomcatServer2 > takes 16 seconds to execute the query aproximately. If I open > only one > browser session to execute the query, then the query takes > only 3 seconds. > > Why does the performance go down? > Why can I correct it? > > THANKS > > Schroeder, Alexander wrote: > > >Hello Bodo, > > > >1. If a client crashes, the serve detects the broken > connection and performs a rollback. This happens almost immediately > > for clients connecting using TCP/IP. > > > >2. Transactions will have locks on some rows, and long > running transactions will surely collect more locks than > > short running transactions, increasing the possibility > that these transactions collide and have to wait. > Unfortunately, there's never > > a general way to solve issues related to locking, you > need them to analyze on a case-by-case basis. > > > >Regards > >Alexander Schr�der > >SAP DB, SAP Labs Berlin > >________________________________ > > > >From: Bodo.Teichmann [mailto:[EMAIL PROTECTED] > >Sent: Monday, February 14, 2005 9:03 PM > >To: [email protected] > >Subject: Re: AW: Release transaction??? > > > > > > > > Hi, > > ...but what if the client crashes in the middle of a > transaction? how long will sapdb keep the transaktion locks > before it release it? > > and another question (motivated to some strange sapdb > behavior, that we saw recently during havy load test of our > tomcat application): > > are there any problems known in sapdb concering > transaktion locks? especially if multiple clients start > transaktions but need a long time to commit them. > > seems that sapdb has problems handling such situations > , when there are many still uncommitted transaktions. but we > did not yet fully analize the problem. > > does anyone have observed (and hopefully solved) > similar problems ? > > Bodo Teichmann > > > > > > Zabach, Elke schrieb: > > > > Jos� R�mulo El�as Contreras wrote: > > > > > > Hi: > > > > I have an application running > over tomcat and with SAPDB > > 7.4.3.30, but I have I problem: Some > times SAPDB hold a transaction and > > does not release it. In the knldiagerr appears: > > > > > -------------------------------------------------------------- > ------------ > > ------ > > Date Time TID(hex) Typ > MsgID Label Message-Text > > > -------------------------------------------------------------- > ------------ > > ------ > > 2004-11-22 08:51:18 > --- Starting GMT > > 2004-11-22 08:51:18 7.4.3 > Build 030-123-056-274 > > 2004-12-04 10:31:12 0x768 ERR > 18431 MESSAGES Could not write to > > event log, rc = 31 > > 2004-12-04 10:34:44 > --- Starting GMT > > 2004-12-04 10:34:44 7.4.3 > Build 030-123-056-274 > > 2004-12-04 14:23:59 0x744 ERR > 18431 MESSAGES Could not write to > > event log, rc = 31 > > 2004-12-04 20:26:11 > --- Starting GMT > > 2004-12-04 20:26:11 7.4.3 > Build 030-123-056-274 > > 2004-12-09 15:02:57 > --- Starting GMT > > 2004-12-09 15:02:57 7.4.3 > Build 030-123-056-274 > > 2004-12-20 08:30:29 > --- Starting GMT > > 2004-12-20 08:30:29 7.4.3 > Build 030-123-056-274 > > 2004-12-23 08:54:48 > --- Starting GMT > > 2004-12-23 08:54:48 7.4.3 > Build 030-123-056-274 > > 2005-01-08 18:45:31 > --- Starting GMT > > 2005-01-08 18:45:31 7.4.3 > Build 030-123-056-274 > > 2005-01-10 19:17:34 0xA0C ERR > 18431 MESSAGES Could not write to > > event log, rc = 31 > > 2005-01-11 08:23:51 > --- Starting GMT > > 2005-01-11 08:23:51 7.4.3 > Build 030-123-056-274 > > 2005-01-14 13:11:54 > --- Starting GMT > > 2005-01-14 13:11:54 7.4.3 > Build 030-123-056-274 > > > > What does "Starting GMT 2004-11-22 > 08:51:18" means, and why this appear > > in the knldiagerr? > > > > > > > > knldiagerr will not help in any case to answer > you transaction question. > > If YOU/the application does not send > COMMIT/ROLLBACK to the database system, then the current > transaction remains open, the locks remain. > > And during the current transaction there were > several INSERT/UPDATE/DELETE made for table > DBA.ACCOUNTS_RECEIVABLE. And that transaction was neither > commited nor rollbacked at the point of time you selected > lockstatistics. > > Everything seems to work correctly, exactly one > transaction is open. Why doe you think that this wrong? > > > > Knldiag.err is the error-log of database system > for strong errors. Knldiag is the file whose writing starts > anew with each start of the database system. Knldiag.err is > written more seldom, but for a longer time period. And > Starting means, that the database system was started at that > (GMT) time and the given version of the database kernel was > used for this start. > > > > Elke > > SAP Labs Berlin > > > > > > > > What does " 0xA0C ERR 18431 MESSAGES > Could not write to event log, rc = > > 31" means? > > > > I can see that in the last transaction > that was holding and was not > > realease, appears the next information > in the lock statistics table: > > > > *SESSION* *TRANSCOUNT* > *SUB_TRANS* *WRITE_TRANS* > > *PROCESS* > > *USERNAME* *DATE* *TIME* > *TERMID* *REQ_TIMEOUT* > > *LAST_WRITE* > > *LOCK_MODE* *LOCK_STATE* > *REQ_MODE* *REQ_STATE* > > *APPL_PROCESS* > > *APPL_NODEID* *OWNER* > *TABLENAME* *TAB LEID* *ROWID_LENGTH* > > *ROWID_HEX* *ROWID* > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > ACCOUNTS_RECEIVABLE > 00000000000002A6 7 > > 00C91391574750000000000000000000 0 > 139157475 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > DETALLE_ASIGNACION_VEHICULOAO > 00000000000002D5 7 > > 00C91391571670000000000000000000 0 > 139157167 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > DETALLE_ASIGNACION_VEHICULOAO > 00000000000002D5 7 > > 00C91391571690000000000000000000 0 > 139157169 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > DETALLE_ASIGNACION_VEHICULOAO > 00000000000002D5 7 > > 00C91391571710000000000000000000 0 > 139157171 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > DETALLE_ASIGNACION_VEHICULOAO > 00000000000002D5 7 > > 00C91391571730000000000000000000 0 > 139157173 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > FACTURACION_AO 00000000000002DE > 7 00C91391574630000000000000000000 > > 0 139157463 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > INVENTORY_MOVEMENT_DOCUMENTS > 2.00E+008 7 > > 00C91391574730000000000000000000 0 > 139157473 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA PEDIDOS_AO > > 00000000000002F7 7 > 00C91394124160000000000000000000 0 139412416 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > PEDIDO_DETALLE 00000000000002F8 > 7 00C91390608010000000000000000000 > > 0 139060801 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > WF_KEYSGENSAP 357 3 > 00C21200000000000000000000000000 0 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > WF_KEYSGENSAP 357 3 > 00C22200000000000000000000000000 0 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > WF_KEYSGENSAP 357 7 > 00C91045100430000000000000000000 0 > > 104510043 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > WF_PATH_HISTORYSAP > 000000000000035A 7 > > 00C91391574650000000000000000000 0 > 139157465 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > WF_PATH_HISTORYSAP > 000000000000035A 7 > > 00C91391574670000000000000000000 0 > 139157467 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > WF_PATH_HISTORYSAP > 000000000000035A 7 > > 00C91391574690000000000000000000 0 > 139157469 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > WF_PATH_HISTORYSAP > 000000000000035A 7 > > 00C91391574710000000000000000000 0 > 139157471 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > WF_PATH_HISTORYSAP > 000000000000035A 7 > > 00C91391574720000000000000000000 0 > 139157472 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > WF_PATH_HISTORYSAP > 000000000000035A 7 > > 00C91391574740000000000000000000 0 > 139157474 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > WF_PATH_HISTORYSAP > 000000000000035A 7 > > 00C91391574760000000000000000000 0 > 139157476 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA > > WF_PATH_HISTORYSAP > 000000000000035A 7 > > 00C91391574780000000000000000000 0 > 139157478 > > 100046 185074 0 00000006F8FF > 37 DBA 2005-01-31 > > 13:30:03 > > java ? 0 row_exclusive > write ? ? 0 > > app_server DBA CONTACTS > > 481 6 > 00C91120802400000000000000000000 0 > > > > > > Why does SAPDB sometimes not release > the transaction? > > > > THANKS > > > > > > > > -- > > MaxDB Discussion Mailing List > > For list archives: http://lists.mysql.com/maxdb > > To unsubscribe: > http://lists.mysql.com/[EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
