Re: AW: Release transaction???

José Rómulo Elías Contreras Tue, 15 Feb 2005 09:39:55 -0800

Hi,

Yes, it is the difference before calling the execute method and afterwards:

      *// Before execute statement save time (time1)
      ResultSet rs = statement.executeQuery( sql );
      // After execute statement save time (time2)
      // differenceTime = time2 - time1
   *
THANKS


Schroeder, Alexander wrote:

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]

Re: AW: Release transaction???

Reply via email to