Zabach, Elke schrieb:
Claus-Thomas Buhl wrote:What do you mean with `the time between two requests'? Is it the time
> What kind of application do you have?
> Is the session-timeout of 15 minutes ok in this context? It does not seem to be.
We have a Web server application with some middleware that accesses SAP DB (located on the same server) via ESQL/C. Each Web site is mapped to some SAP DB user and there is one database instance for all these users.
The queries on the Web site of interest connect with isolation level 0 and normally run no longer than 3 seconds. Then there is the CMS part of the Web site where queries and updates connect with isolation level 30 and normally run no longer than 5 seconds.
It does not matter how long a query will take, what matters is the time between two requests to the same kernel task (time between answer from the kernel and the next request, to be precise).
between a disconnect and connect, or the time between execution of
2 SQL statements during one connection (connect;exec sql 1;exec sql 2;...;exec sql n;disconnect)? From the documentation of the error message `Session inactivity timeout (work rolled back)' I would imply the latter. Ok, then I have to find out what makes my application wait for 15 minutes between execution of 2 SQL statements. Locks cannot be the reason, since outside the CMS I run in isolation level 0. Right?
In your case, where there may be the next Web-request for this task or not
the SESSION_TIMEOUT of 15 minutes does not seem to be the best decision.
You should increase it (upper limit 32400 seconds) or even destroy it
(SESSION_TIMEOUT = 0). But in the latter case keep in mind that resourses
held by a task never ending by its own, are lost for others. That means,
the task is eaten and will not be freed by the kernel if no requests are there
for it. Locks are not released if no commit/rollback is sent by the application
and so on. Ok, locks are not the main topic for queries and isolation level 0,
but those updates...
Is there a difference between 3 and 30? The documentation says `Isolation Level 3 or 30' assigns a table shared lock (exclusive lock on updates). So for me there is no difference between 3 and 30. Or do you mean that I should use row locks and thus isolation levels 10,15 or 20?BTW: Why do you use isolation level 30 (and not 3)? Is it really necessary to lock the whole table until commit/rollback?
Regards, CTB
Elke SAP Labs Berlin
Regards, CTB
Zabach, Elke schrieb:
Claus-Thomas Buhl wrote:
Hi there,
Is there any documentation on the following SAP DB error message:
Command inactivity timeout (work rolled back) (command
timeout)(63)
Errorcode = 700, ISAM = 0
This error message has the same error code as
`Session inactivity timeout' but obviously relates to an
SQL command,
not to a CONNECT.
What are the reasons for this error? How do I get rid of this error?
Context: SAP DB 7.3.0.32, MAXUSERTASKS=50, MAXSERVERTASKS=15, DEADLOCK_DETECTION=4, SESSION_TIMEOUT 900, REQUEST_TIMEOUT 60
Regards,
CTB --
These are no different errors, just two namings.
Explanation:
An application connects to one task in the kernel and uses
some resources.
To avoid loosing those resources (and not being able to use
that task for
other work) a usertask not used by its application for a
while (longer than
SESSION_TIMEOUT tells this task to wait) will catch that
fact, do a rollback
release implicitly and return error 700 whenever the
application wants to talk
to that kernel-task again. This talking to the task again
is not possible.
A new connection has to be opened by that application
before being able
to talk to a (not necessarily the same) kernel task again.
What kind of application do you have? Is the session-timeout of 15 minutes ok in this context? It
does not seem to be.
Elke
_______ \o/|\o/ Claus-Thomas Buhl | Diplom-Informatiker \_____/ mailto:[EMAIL PROTECTED]
H.E.I. GmbH | Wimpfener Strasse 23 | D-68259 Mannheim
Fon: +49-(0)621-795141 | Fax: +49-(0)621-795161 |
mailto:[EMAIL PROTECTED]
http://www.h-e-i.de && http://www.hei.biz && http://www.radpage.com
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe:
http://lists.mysql.com/[EMAIL PROTECTED]
-- _______ \o/|\o/ Claus-Thomas Buhl | Diplom-Informatiker \_____/ mailto:[EMAIL PROTECTED]
H.E.I. GmbH | Wimpfener Strasse 23 | D-68259 Mannheim Fon: +49-(0)621-795141 | Fax: +49-(0)621-795161 | mailto:[EMAIL PROTECTED] http://www.h-e-i.de && http://www.hei.biz && http://www.radpage.com
-- _______ \o/|\o/ Claus-Thomas Buhl | Diplom-Informatiker \_____/ mailto:[EMAIL PROTECTED]
H.E.I. GmbH | Wimpfener Strasse 23 | D-68259 Mannheim Fon: +49-(0)621-795141 | Fax: +49-(0)621-795161 | mailto:[EMAIL PROTECTED] http://www.h-e-i.de && http://www.hei.biz && http://www.radpage.com
-- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
