Forums

There is hardly any code before I create the logical database and attempt to query it.  After input of the details of the 2 database nodes, I connect them to the session then add them to the logical Id of the same session - all without a hitch.  Then on the very first query it cannot recognise that logical Db name.  the error message implies that it is treated the argument as a normal database name.   (E4083)

 I can see from Eclipse that only one thread running so there is no race condition in the java layer as you imply.

Perhaps it's the way JVI interfaces with the C calls.  Have logical databases ever been implemented with JVI rather than C/C++ or JDO before?  

By inserting the node checks in the following code I found that the connectDatabase() calls do not work.

I could read from  either node in my trial system if I opened the session with it but I could not access either node if I connected it to a session.

****************************************************************************************  CODE **********************************************************************************

// open session then connect all the other shards to the same session

 

session = new TransSession(dbNodes[0].name);this.dbNodeCheck(session, 0, fop);for (it = 1; it < dbNodes.length; it++) {session.connectDatabase(dbNodes[it].name);this.dbNodeCheck(session, it, fop);// }

 

// now create logical database from main and connected databases

 

 

 

);  }

***********************************************************************************END CODE ***************************************************************************************

Does this give any clue as to why this shouldn't work.  As I have written there's only one session being used.  Are any of these calls asynchronous under the JVI hood? 

session.newLogicalDatabase(lName); for ( it = 0; it < dbNodes.length; it++) {session.addToLogicalDatabase(lName, dbNodes[it].name

 

 

 

 

 

 No, the connection is not done asynchronously. TransSession.connectDatabase is a direct call to the native kernel o_connectdb API - it does not return until the connection is made.

I don't know what your nodeCheck method does, but the way to determine whether the connection exists or not is to use "dbtool -trans -info" on the database - you should see your client's session in the transaction list.

We *have* discovered a bug that was causing the code you sent before to fail - the particular query class you are using does indeed not work with logical databases (logical database support was never implemented with the Query or FundQuery class in JVI). This is being discussed currently in Engineering. The older query classes (VQLQuery and FundVQLQuery) do work, although they are no longer fully documented.

Versant Support Team

Code got a bit jumbled up via the pasting tool. here it is again:


// open session then connect all the other shards to the same session
session = new TransSession(dbNodes[0].name);
this.dbNodeCheck(session, 0, fop);
for (it = 1; it < dbNodes.length; it++) {
session.connectDatabase(dbNodes[it].name);
this.dbNodeCheck(session, it, fop);// }
// now create logical database from main and connected databases
session.newLogicalDatabase(lName);
for ( it = 0; it < dbNodes.length; it++) {
session.addToLogicalDatabase(lName, dbNodes[it].name;}

As I wrote, the dbNodeCheck() calls showed that connectDatabase() function di not work.

I tested with the following:

Scanner sc = new Scanner(System.in);
TransSession sess = new TransSession(dbname);
sess.connectDatabase(dbname2);
sc.nextLine(); // wait for keypress

And verified with dbtool, as specified above, that the session was connected to both databases...

>dbtool -trans -info log1
VERSANT Utility DBTOOL Version 8.0.2
Copyright (c) 1988-2011 VERSANT Corporation


** Short transaction Info **

-----------------------------------------------------------------------------------------
Tx ID Coord count flags server[pid.tid] client[pid name] session-name long trans ID
----------------------------------------------------------------------------------------
306.0.18436 y 00000 x0290 07388.06888 06192 gdighton gdighton 6192-033A8990
306.0.18440 y 00000 x0290 01812.07096 01812 gdighton dbtool

>dbtool -trans -info log2
VERSANT Utility DBTOOL Version 8.0.2
Copyright (c) 1988-2011 VERSANT Corporation


** Short transaction Info **

-----------------------------------------------------------------------------------------
Tx ID Coord count flags server[pid.tid] client[pid name] session-name long trans ID
----------------------------------------------------------------------------------------
306.0.18436 n 00000 x0280 04636.03108 06192 gdighton gdighton 6192-033A8990
307.0.18438 y 00000 x0290 04184.04428 04184 gdighton dbtool

(1) Thank you Garth.  I have resolved the problem with connectDatabase(). 
I needed to change the default database every time I switch database nodes.
I guess I could use the  constructor for the Query object that explicitly
names the database node but from the above comment about Query I'm unsure whether it would work.
If it does, is this more efficient than changing the default database?

(2)  I am disappointed that the logical database feature does not work with Query.
I have a database of vertexes that store references to other vertexes.
I believe that the Versant loid includes a component that references the database node of
each referenced object.
Can I therefore assume that I will be able to navigate from vertex to vertex using JVI dereferencing
regardless of which node actually stores the referenced vertex object?

(It would be good to learn that the logical database feature was going to be fixed.)

> I guess I could use the constructor for the Query object that explicitly
> names the database node but from the above comment about Query I'm unsure whether it would work.
> If it does, is this more efficient than changing the default database?
If you only do queries on different databases the Query constructor is the right choice.
If you do all kind of different operations I would prefer changing the default database.
Use whatever makes your code easier to understand from the perspective of a reader new to your application.

> Can I therefore assume that I will be able to navigate from vertex to vertex using JVI dereferencing
> regardless of which node actually stores the referenced vertex object?
Your assumptions are correct and the approach is very efficient. More efficient than queries.