Asynchronous Message-Passing

To support asynchronous, ``server push'' delivery of messages to clients, any client that might need to receive an asynchronous message is assigned a unique ID. These IDs may be retrieved both on the client and on the server, during execution of code related to a client.

$$\begin{array}{l} \mathsf{type} \; \mathsf{client} \\ \math... ...hsf{self} : \mathsf{transaction} \; \mathsf{client} \end{array}$$

Channels are the means of message-passing. Each channel is created in the context of a client and belongs to that client; no other client may receive the channel's messages. Note that here client has a technical Ur/Web meaning so that it describes only single page views, so a user following a traditional link within an application will remove the ability for any code to receive messages on the channels associated with the previous client. Each channel type includes the type of values that may be sent over the channel. Sending and receiving are asynchronous, in the sense that a client need not be ready to receive a message right away. Rather, sent messages may queue up, waiting to be processed.

$$\begin{array}{l} \mathsf{con} \; \mathsf{channel} :: \mathsf... ...; \mathsf{t} \to \mathsf{transaction} \; \mathsf{t} \end{array}$$

The $\mathsf{channel}$ and $\mathsf{send}$ operations may only be executed on the server, and $\mathsf{recv}$ may only be executed on a client. Neither clients nor channels may be passed as arguments from clients to server-side functions, so persistent channels can only be maintained by storing them in the database and looking them up using the current client ID or some application-specific value as a key.

Clients and channels live only as long as the web browser page views that they are associated with. When a user surfs away, his client and its channels will be garbage-collected, after that user is not heard from for the timeout period. Garbage collection deletes any database row that contains a client or channel directly. Any reference to one of these types inside an $\mathsf{option}$ is set to $\mathsf{None}$ instead. Both kinds of handling have the flavor of weak pointers, and that is a useful way to think about clients and channels in the database.

Note: Currently, there are known concurrency issues with multi-threaded applications that employ message-passing on top of database engines that don't support true serializable transactions. Postgres 9.1 is the only supported engine that does this properly.