Ultra Light Client Guide and Reference


ULC and Server Smalltalk

In ULC-packaged images, code runs in background processes that are owned and managed by Server Smalltalk (SST). Messages, both in- and outbound, are processed in UlcRequestProcessor objects that are owned by an instance of either UlcApplication or UlcContext. Messages processed by UlcContext handle initialization and context-specific settings like look-and-feel or local information; they are internal to ULC. Application-relevant code always runs in a process associated with an instance of UlcApplication. For each instance of UlcApplication, no more than one request is being processed at any given moment.

To identify the object for which the current Smalltalk process is running, send the #ulcActiveProcessOwner message. Similarly, the messages #ulcActiveContext and #ulcActiveApplication answer the appropriate object or nil. You can assume the following based on the responses to these messages:

These relationships allow for custom exception handling for each UlcContext object. For more information, see Customizing exception handling by context.

Concurrency issues

When writing server applications, you must address concurrency issues. When dealing with these issues, you must often identify the object space from which an object should be retrieved, based on the active connection or user. ULC allows for but does not directly support the creation of object spaces. In most cases, though, it is enough for the application to be able to identify the context under which it is running. As described previously, the #ulcActiveContext message will provide this information for all processes created or scheduled by ULC. It is up to you to make sure that a UlcContext is set for any processes created by business logic.

To set the owner for an active process, send the Object>>#ulcSetUlcProcessOwnerTo: aUlcProxy while: aBlock message. aUlcProxy must be either a UlcContext or UlcApplication object. aBlock contains the business logic that will be run in the process to be owned by aUlcProxy. In the case where code in business logic has registered for context-related events in UlcContext, aUlcProxy must be set to the active UlcApplication instance.

Within one UlcApplication instance, only one request is active at any given time. The process that actually dispatches the request can be different each time, because ULC maintains a pool of processes to dispatch the requests.

What does this mean for your application?

You must be conscious of this process model if either of the following is true:

This process model is of no consequence if all of the following is true:


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]