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=""

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. 

 

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

some ideas from the hip:

  • classic SOAP service
  • running a background job over ECP
  • having a listening job that triggers whatever you need
  •  using WebSocket communications

They all run over TCP as there is nothing else between separated servers.
At the bottom line, you rely on some code expecting a request.
"Native API" for various languages, or Studio, or CSP do the same over Super Server Port (1972) 
the quality is different, not the principle.