O$: Object vs Object Refence?

Bruno Del Sol bruno.delsol at bydesign.fr
Mon Apr 19 05:55:54 UTC 2021

Hi Paul,

The SQL architecture we use for js apps is :

- each remote task instance has 1 Objectref instance var holding a SQL session

- each remote task instance also has 1 Objectref instance var holding a SQL statement object (some time more than one if 
cursors are needed)

- The SQL session (and statement) are lazy loaded, ie they are initialised and connected only right before the first 
$execdirect occurs during the remote task instance lifetime.

- the main (desktop) task has also its own Objectrefs for 1 session and statement and is also lazy loaded, but 
practically those are used only at launch time to retrieve a bunch of app parameters from the database. It then sits 
idle and is eventually wiped out pretty soon by the RDBMS connection timeout.

Therefore, no open SQL connection is held live.

This setup has proven to be rock solid in production (no Omnis crashes, no memory leaks) on the 3 platforms combined 
with MySQL, PG and MSSQL. It also makes maintenance a lot easier because you can reboot servers or restart services 
(Omnis or rdbms) and your app will still be live as if it didn't happened.

You may think this is too much changes for you app, but I'm not so sure, I was once using sessionpools also, and this 
change is far from being the trickier rewrite we had to do with Omnis over the years.



By Design
Bruno Del Sol
bruno.delsol at bydesign.fr
46, rue de La Tour d'Auvergne
75009 Paris (France)

Le 19/04/2021 à 02:04, Paul Mulroney a écrit :
> Hi Everyone,
> We've been using a class var to hold a Postgres session object ever since we started migrating our software to SQL.  For a recent project, we're going to use one postgres database with multiple schemas, and found that our class var isn't going to work.  The basic issue is that the session holds the current schema, so if you change schemas in one place, the next call elsewhere will use the new schema.
> For our desktop app, that's going to be OK, because it always references the one schema.  However we use the same framework for our jsClient - each connection could potentially reference a different schema.
> My plan was to use a class var for the desktop, and instance vars for the jsClient, and somehow switch between the two.  However, I couldn't find an easy way do that.  The best I could find was to convert the Object to an Object Reference, and then I could easily pick between either the session pool or the class var.
> Next problem: Our typical block of SQL code goes like this:
> Do ioSQL.$mySessionObject returns voSQL
> calculate vsQuery as <something>
> Do voSQL.$execdirect(vsQuery)
> ... etc
> where voSQL is an Object.
> My question: Can I have an Object Reference, and somehow get back to the Object?  Otherwise, there's hundreds of lines of code across dozens of libraries that need to change <groan>
> Regards,
> Paul.
> Why does a chicken coop have two doors? If it had four doors it would be a chicken sedan.

More information about the omnisdev-en mailing list