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?
LOCKS can never be the reason for a SESSION TIMEOUT
> >
> > 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
>
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
