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).

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?

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
> 

-- 
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to