Question
· Feb 25, 2018

com.intersys.globals.GlobalsException occurs when I am trying to call connection.connect() with the correct credentials

I have a simple app which tries to establish a connection with a Cache database instance via Global API for Java:

import com.intersys.globals.Connection;
import com.intersys.globals.ConnectionContext;

public class Assignment {

    public static void main(String[] args) {
        Connection connection = ConnectionContext.getConnection();
        connection.connect("SAMPLES", "_SYSTEM", "SYS");
    }

}

The expection I am getting:

Exception in thread "main" com.intersys.globals.GlobalsException: lc_conn::connect_device returned Db_err: source: lc_conn::connect() message: lc_conn::connect: CacheSecureStart returned -1:

at com.intersys.globals.internal.GlobalsConnectionJNI.connectImpl(Native Method)
at com.intersys.globals.internal.GlobalsConnectionJNI.connect(GlobalsConnectionJNI.java:107)
at com.tobilko.a3.Assignment.main(Assignment.java:17)

  1. The credentials and the namespace are correct.
  2. The Cache instance has been initialised correctly and by instruction.
  3. All the global environment variables including GLOBALS_HOME and DYLD_LIBRARY_PATH have been set.
  4. The following libraries have been soft-linked:

    ln -s $GLOBALS_HOME/bin/libisccache.dylib /usr/local/lib
    ln -s $GLOBALS_HOME/bin/liblcbjni.dylib /usr/local/lib
    ln -s $GLOBALS_HOME/bin/liblcbindnt.dylib /usr/local/lib
    ln -s $GLOBALS_HOME/bin/liblcbclientnt.dylib /usr/local/lib
    ln -s $GLOBALS_HOME/bin/libmdsjni.dylib /usr/local/lib
    
  5. -Djava.library.path=/usr/local/lib has been specified.

  6. The jars have been included.

Any help would be really appreciated.

Discussion (36)0
Log in or sign up to continue

I've tried using intersystems provider for jdbc and it's work fine. Below is the sample.

import com.intersys.jdbc.CacheDataSource;
//C:\InterSystems\HealthShare\dev\java\lib\JDK18\cache-jdbc-2.0.0.jar

public class Assignment {

    public static void main(String[] args) {
        
            ConnectionString = "jdbc:Cache://" + localhost+ ":" + 1972+ "/" + "SYS";
            CacheDataSource ds = new CacheDataSource();
            ds.setURL(ConnectionString);
            ds.setUser(UserId);
           ds.setPassword(Password);

            System.out.println("Connecting to  db....");
            java.sql.Connection dbconnection = ds.getConnection();
            java.sql.Statement stmt = dbconnection.createStatement();

            System.out.println("Fetching Data from db....");
            String sqlQuery = "SELECT * from table";
            ResultSet rs = stmt.executeQuery(sqlQuery );
    }

}

Of course, I read the documentation.

"Unlike the standard Java binding, the Globals API does not use TCP/IP to communicate with Caché. Instead, it used a fast in-memory connection (implemented via standard Java JNI and the Caché Callin API), and runs in the same process as the Caché instance." - that's why JDBC connections may work while Globals API calls may not.

your connection may also fail if you don't  have a free license.  TRYCACHE has just one and can't have more.
 if you have NO licence only 1 user is allowed.
I have no experience on JNI but you might be rejected if you are logged in in parallel on Terminal or Mgmt portal or studio, ...
In this case  log out from any other connection  and try JNI.

http://localhost:57772/csp/sys/mgr/%25CSP.UI.Portal.License.Key.zen

If it's formal valid this should show your license. 
Look for OSX or "platform independent"

http://localhost:57772/csp/sys/op/%25CSP.UI.Portal.LicenseUsage.zen
here you see available licenses and used licenses   

License Unit Use          Local    Distributed 
Current License Units Used    2    2
Maximum License Units Used    2    2
License Units Authorized     10   10 
Current Connections           2    2
Maximum Connections           2    2

 

if the numbers are reasonable your license is OK.
But be aware the free download version IGNORES any license!

I've been checking a lot of stuff, and it's what I encountered after checking available instances:

Configuration 'DEFAULTCACHEINSTANCE' (default)
directory: /DefaultCacheInstance
versionid: 2017.1.1.111.0su
status: down, directory may be deleted

Configuration 'DEFAULTINSTANCE'
directory: /DefaultInstance
versionid: 2016.2.1.803.0
conf file: cache.cpf (SuperServer port = 1972, WebServer = 57772)
status: running, since Mon Feb 26 10:39:27 2018
state: warn

It means I have two instances, the first one was removed, but it still remains default. I've cleared it, now the system recognises one default instance.

Now sudo ccontrol list gives me:

directory: /Cache
versionid: 2016.2.1.803.0
conf file: cache.cpf  (SuperServer port = 1972, WebServer = 57772)
status:    running, since Mon Feb 26 11:47:09 2018
state:     ok

The app gives me:

lc_conn::connect_device returned Db_err: source: lc_conn::connect() message: lc_conn::connect: CacheSecureStart returned -17: <INVALID_INSTANCE>

2017.1.1.111.0su   S stands for single user and is typically a Trial Version with some limits.
U for Unicode
hard to say (for me) if there could be a conflict with the .jars used  
as  you now run 
2016.2.1.803.0 is 8bit  NOT unicode.   
from Terminal  do "WRITE $ZV")  to check the full version
2016.2.1 (Build 803U)    U=UNICODE
2016.2.1 (Build 803)   no U = 8bit.
This should not be an issue with SAMPLES, %SYS,   ... in your case   though....?

 

It's worth to mention that there are no audit logs when I run the application (though the audit feature is enabled and all system events should be logged. It logs JDBC login/logouts, for instance).

The call from this issue https://stackoverflow.com/questions/26104574/issues-while-connecting-to-... was registered, any of my requests wasn't.

From this, I understand that your installation directory is /Cache and /Cache/mgr is the directory of namespace %SYS where System_Management runs. It is where you log in and get directed to SAMPLES by Caché, based on your config file that is then in /Cache/cache.cpf . Caché takes care of it.

Following the last like I found something you should check:

Setting Permissions for Callin Executables on UNIX®

Caché executables, files, and resources such as shared memory and operating system messages, are owned by a user selected at installation time (the installation owner) and a group with a default name of cacheusr (you can choose a different name at installation time). These files and resources are only accessible to processes that either have this user ID or belong to this group. Otherwise, attempting to connect to Caché results in protection errors from the operating system (usually specifying that access is denied); this occurs prior to establishing any connection with Caché. *)

A Callin program can only run if its effective group ID is cacheusr. To meet this condition, one of the following must be true:

  • The program is run by a user in the cacheusr group (or an alternate run-as group if it was changed from cacheusr to something else).

  • The program sets its effective user or group by manipulating its uid or gid file permissions (using the UNIX® chgrp and chmod commands).

Conclusion:
*), In fact, you were never connected to Caché - no audit no other trace 

In addition, I learned that 
JNI access is implemented and handled similarly to C++based CallIn.
So also error messages are similar. 
And  shdir has the same role as IPaddr:port  for TCP connection.

Pls. check if your user is in group cacheusr