The explanation here is the table lock threshold. If a process modifies a certain number of entries within one table without committing it will trigger an escalation from atomic locks per record to a full table lock.

This is configurable but i am not sure about the default value but i think its between 1000 and 10000.

If the lock is triggered essentially all other processes which want to write have to wait until the process has committed its changes which will release the lock.

Solution is to use %NOLOCK if you are sure you will not hit the same record with multiple processes.

Hi,

i am not quite sure why you got BasicAuth enabled on Apache for requests to webservices hosted on IRIS.

I would disable basic auth and use IRIS to authenticate the request, also from a security perspective if the request originates not from localhost i would move to using https.

Main issue with cors is, if the request originates not from the same domain as the target server is in, e.g. server is configured to be at server.sample.loc, that any request not coming from same domain would trigger a cors deny e.g. ip address only.

As cors is only enforced in the browser not the server the question also is how do you call the webservice? From another production? If so, don't care about cors its than only an issue when testing via your browser.

Best Regards

Timo

Hi Mack,

there are a couple of ways to move the installation across.

One very simple way is by ,as already has been mentioned, shutting down cache and then copy the cache.dat files across for example using ftp.

Another way is using the build-in backup utility to take a backup and restore the backup on your new system,. this does not require a shutdown of cache on either side.

Also make sure you grep a copy of the original cache.cpf file as this contains all the database,namespace and mapping information.

You can easily enough modify the new cache.cpf file accordingly (although this requires then a cache restart to activate the changes).

Cheers