Claus-Thomas Buhl wrote: > > Zabach, Elke schrieb: > > > 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? >
Good question, ask your application, the kernel is just waiting. Is there too much user-terminal-interaction needed (the user going to fetch coffee or so..)? Is there an application level distributing work for the kernel on several kernel-tasks and one kernel-task does not receive any work to do (the others do all what is needed) ? Is there an application working with more than one connection to (one or different) databases and the second connection does a loooooooong lasting query and was written in a way that during that time no other work can/will be done with our session ? Elke SAP Labs Berlin > 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] > -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
