nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Acquire Database connection on server startup (10.5)

FAMELIARISA

Greetings people

The thing I am trying to accomplish, is that I have added to the Application globals some features that exist in a module (let's call it MyModule), and I need them to have values on startup by acquiring them from the database. Let's also assume that the Application globals part of MyModule is called Utils (hence a $MyModule.Utils.XXXXX is visible anywhere)

In order to do that I need to get a CAPICONNECT or a PrgCtx. I opted for the second solution and I used the following code, inside MyModule::MyModuleRoot::Startup method:

Dynamic prgCtx = $DBWIZAPI.DBWizApiSubsystem.SetUpWizData().GetPrgCtx().prgCtx

$MyModule.Utils.fTestPrgCtx = prgCtx

Dynamic results = CAPI.Exec(prgCtx.fDbConnect.fConnection, "SELECT SYSDATE FROM DUAL") // NOT THE ACTUAL QUERY OFC

$MyModule.Utils.fTestDatabaseResults = results

So at this point this code should run on startup but unfortunately, when the server is loaded, I use a script to echo the values of $MyModule.Utils.fTestDatabaseResults and I get undefined.

Any chance to acquire database connectivity on startup? Or is there a global Startup object on 10.5 that runs after everything is loaded and dftConnection is established so that I can plug my startup config code in it (Something that I would personally like to avoid because I want my code to reside inside my modules).

Thank you very much in advance

Find more posts tagged with

Comments

Appu_Nair1

Ideas GaloreJ

If you actually search in the forums many oscript pundits among them David Templeton advises you not to do this. If you actually look the bootstrapping is basically initializing all objects and

Trying to talk to all subsystems and become stable in a short while so when encountering code that I inherited/wrote over the years I have been careful to work around the logic. Perhaps the

very first attempt to a RH, that could define a method which takes the prgCtx passed in and talks to the database and updates a global (or better still even memcached J)so that subsequent calls on that thread don’t have to do it again.

Having said that I have seen OT using the $CurrentWIZAPI in their code so this works in my CS10.5

//cut and pasted from working code with things removed for clarity.

Object prgCtx

Dynamic checkVal = $CurrentWIZAPI.GetPrgCtx()

if ( checkVal.ok ==TRUE )

prgCtx = checkVal.prgCtx

globals.fInitializedData=.DoDatabaseActivitiesWithThatPrgCtx(prgCtx)

echo("from startup")

end

Other advanced methods remain like if you were to look at how OT does patching, but the fact of the matter is you should write code that will not crash the server

because it is quite normal to connect a fully loaded(including your modules and ot optional modules) binary and then connect to a database using the

db connection routine that you do when you setup livelink for the first time and to be quite honest I have seen OT modules in the past trying to find a volume before

the db connection happens. Perhaps with greater emphasis on connections in new code those code streams are much better handled now…

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Wednesday, December 03, 2014 4:46 AM
To: eLink Recipient
Subject: [EXTERNAL]Acquire Database connection on server startup (10.5)

Acquire Database connection on server startup (10.5)

Posted byfameliarisa@unisystems.gr (FAMELIARIS, ATHANASSIOS) On 12/03/2014 05:42 AM

Greetings people

In order to do that I need to get a CAPICONNECT or a PrgCtx. I opted for the second solution and I used the following code, inside MyModule::MyModuleRoot::Startup method:

Dynamic prgCtx = $DBWIZAPI.DBWizApiSubsystem.SetUpWizData().GetPrgCtx().prgCtx

$MyModule.Utils.fTestPrgCtx = prgCtx

Dynamic results = CAPI.Exec(prgCtx.fDbConnect.fConnection, "SELECT SYSDATE FROM DUAL") // NOT THE ACTUAL QUERY OFC

$MyModule.Utils.fTestDatabaseResults = results

So at this point this code should run on startup but unfortunately, when the server is loaded, I use a script to echo the values of $MyModule.Utils.fTestDatabaseResults and I get undefined.

Thank you very much in advance

[To post a comment, use the normal reply function]
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

FAMELIARISA

I have also performed some attempts with $CurrentWizAPI and the rest of these subsystems but unfortunately they seem to perform correctly only when everything is loaded up - and really I don't want to connect to the underlying database by conjuring up CAPI.AllocConnect directly, because ofc the credentials and the database info are different for every installation.

But so far, the Startup procedure doesnot want to play nicely with the DBWIZAPI, unfortunately. Everything I have tried so far does NOT yield results - but of course I may have overlooked some methods.

The reason I do it is that I have some configuration tables that allow for quick alterations and updates of functionality simply by importing new lines into them.

Quoted Appu Nair on 12/03/2014 04:02 PM:

Ideas Galore J

If you actually search in the forums many oscript pundits among them David Templeton advises you not to do this. If you actually look the bootstrapping is basically initializing all objects and

Trying to talk to all subsystems and become stable in a short while so when encountering code that I inherited/wrote over the years I have been careful to work around the logic. Perhaps the

Having said that I have seen OT using the $CurrentWIZAPI in their code so this works in my CS10.5

//cut and pasted from working code with things removed for clarity.

Object prgCtx

Dynamic checkVal = $CurrentWIZAPI.GetPrgCtx()

if ( checkVal.ok == TRUE )

prgCtx = checkVal.prgCtx

globals.fInitializedData=.DoDatabaseActivitiesWithThatPrgCtx(prgCtx)

echo("from startup")

end

Other advanced methods remain like if you were to look at how OT does patching, but the fact of the matter is you should write code that will not crash the server

because it is quite normal to connect a fully loaded(including your modules and ot optional modules) binary and then connect to a database using the

db connection routine that you do when you setup livelink for the first time and to be quite honest I have seen OT modules in the past trying to find a volume before

the db connection happens. Perhaps with greater emphasis on connections in new code those code streams are much better handled now…

Acquire Database connection on server startup (10.5)

Posted by fameliarisa@unisystems.gr (FAMELIARIS, ATHANASSIOS) On 12/03/2014 05:42 AM

Greetings people

In order to do that I need to get a CAPICONNECT or a PrgCtx. I opted for the second solution and I used the following code, inside MyModule::MyModuleRoot::Startup method:

Dynamic prgCtx = $DBWIZAPI.DBWizApiSubsystem.SetUpWizData().GetPrgCtx().prgCtx

$MyModule.Utils.fTestPrgCtx = prgCtx

Dynamic results = CAPI.Exec(prgCtx.fDbConnect.fConnection, "SELECT SYSDATE FROM DUAL") // NOT THE ACTUAL QUERY OFC

$MyModule.Utils.fTestDatabaseResults = results

So at this point this code should run on startup but unfortunately, when the server is loaded, I use a script to echo the values of $MyModule.Utils.fTestDatabaseResults and I get undefined.

Thank you very much in advance

[To post a comment, use the normal reply function]
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

Appu_Nair1

In that case orphan a root of an important module in your module so your module will wait until that module is loaded. If you look at the thread log you should see the load order.

Frankly in my case the CurrentDbwizapi has a value after startup, so if you look at your “global variables” you can see that.

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Wednesday, December 03, 2014 8:14 AM
To: eLink Recipient
Subject: [EXTERNAL]RE Acquire Database connection on server startup (10.5)

RE Acquire Database connection on server startup (10.5)

Posted byfameliarisa@unisystems.gr (FAMELIARIS, ATHANASSIOS) On 12/03/2014 09:02 AM

The reason I do it is that I have some configuration tables that allow for quick alterations and updates of functionality simply by importing new lines into them.

Quoted Appu Nair on 12/03/2014 04:02 PM:

Ideas GaloreJ

If you actually search in the forums many oscript pundits among them David Templeton advises you not to do this. If you actually look the bootstrapping is basically initializing all objects and

Trying to talk to all subsystems and become stable in a short while so when encountering code that I inherited/wrote over the years I have been careful to work around the logic. Perhaps the

Having said that I have seen OT using the $CurrentWIZAPI in their code so this works in my CS10.5

//cut and pasted from working code with things removed for clarity.

Object prgCtx

Dynamic checkVal = $CurrentWIZAPI.GetPrgCtx()

if ( checkVal.ok ==TRUE )

prgCtx = checkVal.prgCtx

globals.fInitializedData=.DoDatabaseActivitiesWithThatPrgCtx(prgCtx)

echo("from startup")

end

Other advanced methods remain like if you were to look at how OT does patching, but the fact of the matter is you should write code that will not crash the server

because it is quite normal to connect a fully loaded(including your modules and ot optional modules) binary and then connect to a database using the

db connection routine that you do when you setup livelink for the first time and to be quite honest I have seen OT modules in the past trying to find a volume before

the db connection happens. Perhaps with greater emphasis on connections in new code those code streams are much better handled now…

Acquire Database connection on server startup (10.5)

Posted by fameliarisa@unisystems.gr (FAMELIARIS, ATHANASSIOS) On 12/03/2014 05:42 AM

Greetings people

In order to do that I need to get a CAPICONNECT or a PrgCtx. I opted for the second solution and I used the following code, inside MyModule::MyModuleRoot::Startup method:

Dynamic prgCtx = $DBWIZAPI.DBWizApiSubsystem.SetUpWizData().GetPrgCtx().prgCtx

$MyModule.Utils.fTestPrgCtx = prgCtx

Dynamic results = CAPI.Exec(prgCtx.fDbConnect.fConnection, "SELECT SYSDATE FROM DUAL") // NOT THE ACTUAL QUERY OFC

$MyModule.Utils.fTestDatabaseResults = results

So at this point this code should run on startup but unfortunately, when the server is loaded, I use a script to echo the values of $MyModule.Utils.fTestDatabaseResults and I get undefined.

Thank you very much in advance

[To post a comment, use the normal reply function]
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

[To post a comment, use the normal reply function]
Topic:	Acquire Database connection on server startup (10.5)
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

FAMELIARISA

I tried orphaning DBWizApiSubsystem in my module. Unfortunately still I cannot get a prgCtx.

After some digging around and even when I directly assigned on Startup to a MyModule feature the whole DBWizApi, I found out that this statement:

$Kernel.SystemPreferences.GetPrefGeneral( 'DftConnection' )

does not return anything on Startup. Or at least when MyModule loads.

Could you provide a Startup script example that actually connects to the content server database and retrieves a value?

Thank you very much in advance

David Templeton

ok first things first and I am going to put this as nice as I can since I have seen this so many times

DO NOT ACCESS THE DATABASE ON STARTUP. PERIOD

the database and other software is not fully loaded when the ospaces __Init is called. And operations like patching, dbupgrades etc have not been completed. Not to mention the DB access may not be present.

Ideally, such data loading should be done on first access. OR, since both KIni and the file prefs are cached by the server, why preload? If the structure is complex then I would say use the threadcache object that is available. It allows complex configuration data to maintained in memory and triggers reload when updates are made.

Now we are looking at adding in a subsystem that can be hooked into to allow the loading of configuration data prior to binding to the port and accepting user requests. IF you are interested in such functionality, contact support and add you name to LPAD-41627.

David

John W. Simon, Jr.

What about making use of PostPatchActions (we could have that call a script to set some global variables). Would we be able to count on DB Access at this point?

David Templeton

It is not an ideal place either since the post patch is meant for ( in the ideal world ) re-registration of objects to various subsystems. Now, I have seen solutions load data at this point as well BUT again, you are in an unknown state since a solution has no clue about other post patch actions

As stated there are currently three recommended ways of loading cache data

<![if !supportLists]>1. <![endif]>Threadcache

<![if !supportLists]>2. <![endif]>On execution of the solutions utility function and it is somehow saved

<![if !supportLists]>3. <![endif]>Just use the CAPI.INI* functions directly

David

FAMELIARISA

Okay then, let me restate my original question:

I need to have some information loaded from the database after server startup but before anyone logs for the first time. Before the server is accessible to anyone. Is there a specific subsystem / class I should orphan, a specially named feature I should create or anything else?

Pray do tell.

Hans Stoop

It is still not clear to me why you can’t load the data the first time you need it. That would be the best approach.

Hans

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Freitag, 5. Dezember 2014 10:10
To: eLink Recipient
Subject: RE RE RE Acquire Database connection on server startup (10.5)

RE RE RE Acquire Database connection on server startup (10.5)

Posted byfameliarisa@unisystems.gr (FAMELIARIS, ATHANASSIOS) On 12/05/2014 04:03 AM

Okay then, let me restate my original question:

Pray do tell.

[To post a comment, use the normal reply function]
Topic:	Acquire Database connection on server startup (10.5)
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

David Templeton

I am going with Hans on this one, why cannot this be done? We seem to missing a piece of information

David

Chris Meyer

David: I agree the database shouldn't be accessed at startup for reasons mentioned here, although I wish it were possible. I often want to initialise something at startup based on a setting, but since we can't store the setting in the database we're left with the opentext.ini file. However, I've also heard from OpenText this is not recommended (i.e., use KINI instead).

Nonetheless, you might want to know that CS10.5 (update 2014-09) accesses the database at startup. In llweb_startup.lxe you'll find this:

// Populate the DTreeSubTypeOrderRef tableif( System.ThreadIndex() <= 1 )    DBWIZAPI::Utility.PopulateDTreeSubTypeOrderRef()end

The PopulateDTreeSubTypeOrderRef() gets a prgCtx from the wizAPI before executing a bunch of SQL calls with it. I'm not sure if this is an exception, but there it is.

David Templeton

Chris

I know of the exception mentioned. That is why I have been looking at seeing us provide a subsystem that ensure an entry point after all low level stuff is done, patching is done, schema upgrades are done BUT just before the port is bound to.

David

HFCDev

I'll chime in on this one....here's a potential use case of why you'd need to access the database. I think Chris already hit the nail on the head when he said if you have config settings that you need to access at startup, you're only option is the opentext.ini file....which we're being discouraged from using (and for good reason, you end up having to repeat your settings on EVERY SINGLE INSTANCE in the cluster).

I was exploring an idea for my client to add dynamic menus and menu items. I was going to store the menu config in KINI (i.e. new menu name & ID + a list of settings for each menu item configured). At startup, my LivelinkGCnavCallback object would execute the $WebLL.WebUtils.Addmenu() function which needs to run at startup.

Now, unless I can get away with running the AddMenu() command from within my CB's Execute method, I would need the prgCtx at startup. I'm playing around with this now.. Bottom line for me, I want to avoid stuffing ANYTHING extra into opentext.ini.

-Hugh

Chris Meyer

Hi Hugh: CS16 has a new $LLIAPI.StartupInitialization subsystem for running stuff with a database connection after everything else has completed. This is likely what David was referring to and might help you.

HFCDev

It might in about 2 years time when CIC moves to CS 16. Actualy, the main reason I'm in this orgy of customization is because CS 10.0 is on the last release with no further updates, and we're eeons away from an upgrade due to downtime constraints.

-Hugh

David Templeton

Hi Hugh

Let’s go through a couple of things, first off the DB is the correct place for configuration settings for the cluster, period. Now the __Init is not the place for the obvious reasons we have described in previous posts but let’s add one more. We have been chasing issue where solutions have been creating a connection to the database in the __Init and not cleaning up after themselves, leaving a db connection hanging and in turn we can run out of connections ( Oracle hard limit of 2000 ).

Is the currently supported menu extension not enough? If not, that is fine. But as Chris has mentioned, and I would agree, have you tried on prgCtxLoginCallback or something similar then only doing it once and then setting a thread global?

Well, this leaves you and the customer in a precarious position, since you know that db access in the __Init is highly discouraged.

In another post, you mention the customer will not be upgrading for 2 years? Why is that? How big of a system? And you said 10.0? That is a scary place to remain due to security concerns etc. Should the customer be contacting support to assist with upgrade plans?

Regards

David

HFCDev

Hi Chris,

Well, won't help me right now as CS 10.0 isn't going anywhere, but I did discover that you can build the menus as a lazy load, i.e. you don't need to add them to the registry at start-up, only when the user first accesses them. It will be a pretty cool module when I'm done.

-Hugh

HFCDev

Hi David,

For this particular customization, I did succeed in a lazy load approach so I'm not touching the database during __Init() but only accessing the additional config when the LivelinkGCCallback object is first executed (which is always with a valid prgCtx). The only side effect is that on first load of the page, you don't see the new menu items but you do see them on subsequent loads of the page.

As to your question about the lack of upgrade, our issue is that our instance has grown too big to be upgraded in a timely manner. The operational constraints are that we are simply not allowed to be down for more than 15 minutes in a given week. They've talked to OT support and OT services several times to come up with a way to do an upgrade where the system is never down for more than 15 minutes in a single week, and never read-only for more than 1 hour. So far, neither could give a solution. And so far, every solution I've proposed to get the client off CS 10.0 to CS 10.5 or better has been rejected. And yes, I know, something has to give, and probably catastrophically

-Hugh