New post
AllAccepted answers
Robert Cemper · Sep 23, 2020

Depending on how you have built your WebAPI every request may run its own session with its own job id.
CSP has the concept of a SessionID to bypass such problem.
But it requires that you pass the Id back to the client and clean it up once done.

You may follow this philosophy using a random unused key [ $D(^SORT(key))=0 ]  instead of $J that you pass back to the client.
Cleaning it up is a good practice to avoid to much waste in your global. [ BTW. also with $JOB ]

 

Robert Cemper · Sep 18, 2020

Hi  @Dan Pahnke 
The "Red Fire Button"  is a synonym I used over the years with my various teams for an action/decision
that should not be taken by a single person but follows (at least) the 4-eyes-principle.

Inspired by an endless number of Airforce fighting movies from Hollywood and
the old but still incredible song from The Dubliners.
And its best cover version

Robert Cemper · Sep 18, 2020

#1)  check that ALL code Dbs are part of your Mirror. 
There is a fair chance that not all code you use is in a single code DB but is mapped to other DBs.
I'm not talking about implicitly mapped pieces like all System and %* Utilities.
#2) If  you use code mapping It is highly important that Package mapping AND routine mapping go hand in hand
#3) Whatever Mirror is synchronizing is based on Global Journal. So also all code DBs require Journalling.
    Since every routine or class whether deployed or not is stored in some global.

But my personal preference is not to apply Mirror to code DBs.
Mainly to control the point in time when a Change/Update happens.  
I'm a fan of the Red Fire Button and like to control the moment  of essential changes
 

Robert Cemper · Sep 15, 2020

Typically a %ResultSet is an object. It is destroyed as soon as you de-reference it.
This could be a ba killing the referencing variable or by assigning a different value.
there is no need for a %Close or an object destructor.  this happens implicitely.

set rs= ##class(%ResultSet).%New()
. . . . ; work it 
kill rs
; or 
set rs=""
Robert Cemper · Sep 15, 2020

What you see could be explained best by "model mismatch"
Java Gateway connection stays as long as the connecting process exists.
While CSP.REST services a  request and stops.
To avoid repeated connection times you may run some background process as worker jobs that open Java Gateway
and get its requests from your CSP.Rest.
As you have Ensemble already, you might run your Java Gateway as a Business Service connecting OnInit() an stay connected.
This is of course all asynchronous processing which affects your response time.

If you revert it and a Java process is scanning request using Native API for Java I wouldn't expect more attractive timing.