> LOCKS can never be the reason for a SESSION TIMEOUT
So what could be the reasons for a SESSION TIMEOUT? What could make the execution of an SQL statement wait for (more than) 15 minutes?
Regards, CTB
Claus-Thomas Buhl wrote:
Zabach, Elke schrieb:
Claus-Thomas Buhl wrote:
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).
What do you mean with `the time between two requests'? Is it the time
between a disconnect and connect,
NO
or the time between execution of
2 SQL statements during one connection (connect;exec sql 1;exec sql 2;...;exec sql n;disconnect)?
YES
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...
BTW: Why do you use isolation level 30 (and not 3)? Is it really necessary to lock the whole table until commit/rollback?
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.
Correct with the current version. But 30 has a good chance to be destroyed
in some later version, whereas 3 will remain longer.
It was just a remark so that changes in your coding when using some future version of MaxDB are less likely.
Or do you mean that I should use row locks and thus isolation levels 10,15 or 20?
No
Elke SAP Labs Berlin
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
-- _______ \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]
