Skip to Content

DB locking when calling SP from xsjs

All,

I have a piece of XSJS code that calls a SP. We discovered a bug in a developer while testing, we omitted the connection.commit() and connection.close() statements in our code which locked everyone else in the team and we couldn't activate any files. This system is on SP8 (1.0.81). We tried recreating the same issue on a different system running SP7 (1.0.70) and the issue is not occurring. We can successfully call the stored procedure from another application with the correct format of commit() and close(). Further, out SP7 system also executes the stored proc and allows everything else even when we omit the commit and close statements in the code, etc.

Is there a bug on SP8 that locks the db when issues like this happen? Is everyone using the same DB connection? if the db hangs there due to bad code... how can we kill the process? we are unable to kill the process itself using the SQL statement, ALTER SYSTEM CANCEL \[WORK IN\] SESSION session_id  and it forces us to bounce the HANA DB which is not ideal. Luckily we are in dev and not in prod yet.

any help, direction or documentation is greatly appreciated

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Jul 22, 2014 at 08:05 AM

    Hi Sergio,

    this question would be better placed in SAP HANA and In-Memory Computing as you ask about a complete database hanging situation.

    Among the meanwhile sizable number of threads around cancelling/killing/stopping sessions and threads in SAP HANA, this one might be best answering your question.

    Bottom line is: in case the session doesn't end itself in a reasonable time frame after you issued the cancellation command, then the only way to stop this session is to restart the HANA instance.

    Before restarting you should however be sure that you actually cannot just let it sit that way until you can conveniently restart the instance.

    Obviously this is not a nice thing to have, therefore opening a support incident for further inspection should be part of the restart action. Make sure to take some runtime dumps before doing so, since otherwise there is no way for the development colleagues to figure out why the session was unresponsive.

    - Lars

    Add comment
    10|10000 characters needed characters exceeded