AllAccepted answers
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. 

 

Robert Cemper · Sep 14, 2020

BIG THANKS to @Dan Pasco for sharing this example: 

The test is simple - I am running in the 2020R1 instance, namespace USER and there are no classes runnable in this namespace - just a clean, new install. I have several other instances running, all different versions/build numbers. I am testing against my XDBC instance which is currently labeled as 2020.4 (obviously not yet released but the IRIS Native code is essentially the same as in 2020.1). The XDBC instance is listening on port 51780. First, proof this doesn't work locally.

USER>write ##class(Sample.Person).CurrentAge($h-35000)                 

WRITE ##CLASS(Sample.Person).CurrentAge($H-35000)
^
<CLASS DOES NOT EXIST> *Sample.Person

And then, attempt the same function using the IRIS Native connection to the XDBC instance.

USER>set host="localhost",port=51780,namespace="USER",user="_SYSTEM",pwd="SYS" 

USER>set connection = ##class(%Net.DB.DataSource).CreateConnection(host, port, namespace, user, pwd)

USER>set iris = connection.CreateIris()                                                             

USER>write iris.ClassMethodValue("Sample.Person","CurrentAge",$h-35000)                             
95