serverExecution Method Option

The serverExecution method option historically was used a lot, prior to the introduction of Jade thin client. Jade nodes (fat clients) were on people's workstations and it was indeed a long way to go over the network to the database server. Saving trips to the server was much more important back then, and saving trips is primarily what this method option is used for.

Nowadays, most end‑users are on thin clients and most nodes are on the same physical machine as the database server, using the HPSM or JadeLocal transport (shared memory). Saving trips to the server is not nearly as important now. However, it still can be important.

In Jade 6, excessive use of serverExecution could result in node contention, especially if large numbers of objects were being fetched from the database. With Jade 7 and higher, that node contention is effectively removed, meaning that you can feel more free to use serverExecution.

The serverExecution method option is useful in the following situations.

• A lot of database objects need to be retrieved and very little information is returned.

• A lot of updating is done, with little code execution in between; for example, cloning a number of persistent objects.

• A centralized location is required; for example, keeping track of the next global unique number to be used.

However, be aware that there are some pitfalls, including the following.

• The method is executed on a server long thread. If you increase the amount of server executions, you may need to increase the value of the MaxLongThreads parameter in the JadeServer section of the Jade initialization file.

• Assuming you are using multiple method caches, the method cache of the server thread is inherited from whatever had run there before ‑ how likely is your method to be in that cache?

  You could use a single method cache in the server node to avoid this, but that increases contention in the method cache, which in turn is likely to reduce overall performance.

• The server's object cache is used, rather than the node's. This could be a good thing or a bad thing.

  If you are reading objects that are not in the node cache and would not be helpful in the node cache, it is a good thing.

  If you access objects that were already in node cache, time is spent bringing them into the server cache as well.

  If you had already updated the objects in the node cache in the same transaction, they have to be fetched from the client node.

• Accessing transients can be expensive if they are created on one node and used on another, as they must be copied back and forth. Does your server execution method contain references to app?

• Calling a client execution method from a server execution method is expensive, and it leaves the server thread in use. Passing transients back and forth becomes even more expensive.

The serverExecution method option is more useful than ever, but measure the difference it makes, if at all possible.

However, beware of the effects of micro‑benchmarking (see "Micro‑Benchmarking – Measure as You Go", earlier in this document). In addition, a server execution test will clearly run faster when no one else is using the database. It might be a lot slower during normal production, when the database is more‑heavily loaded.