<!--toc--> |
|
## Introduction |
|
CppCMS is designed for high performance and thus it "caches" anything possible. Same the application objects. |
|
Before we begin, it is very important to distinct between two types of applications (classes derived from `cppcms::application`): |
|
1. **Synchronous applications** - the most common type of applications: the ordinary applications that are designed to handle normal request. |
2. **Asynchronous application** - the special applications that are designed to handle multiple request and support long pooling. |
|
## Synchronous Applications |
|
### Single Application |
|
Synchronous applications live in a pool. They are generated by a special `cppcms::applications_pool::factory` object |
that is mounted to the [`applications_pool`](/cppcms_ref_v0_99/classcppcms_1_1applications__pool.html) object. |
|
These object are long-living object and once they created |
they are usually cached in the pool for future reuse. |
|
Upon incoming request the application if fetched from the |
pool or new one is created. The special `cppcms::http::context` object is assigned to the application during all request processing, |
|
This request is processed in the thread pool by |
calling the `application::main()` virtual function |
that actually handles the request. |
|
Once the request is complete, this context is unassigned |
and the application is returned back to the pool |
for future reuse. |
|
So when your write your own applications, you may assume |
that their constructors are not called frequently. You should also assume that they will "kept alive" for a long time. |
|
It is good idea to cache some general non-mutable |
information withing such object. |
|
### Applications with Children |
|
Each application can have multiple children applications, for example: |
|
blog |
admin |
post_editing |
options_editing |
display |
post |
summary |
feeds |
atom |
rss |
|
|
Each child application can be connected to the parent |
via [`add` or `attach`](/cppcms_ref_v0_99/classcppcms_1_1application.html) member functions |
in the constructor. Each application shares its lifetime and its `cppcms::http::context` with its parent. |
|
Even thou they are different object and different |
classes they are tightly bounded and live |
together as long as topmost-parent lives, `blog` in our case. |
|
|
## Asynchronous Applications |
|
### Lifetime |
|
Unlike synchronous applications that have multiple |
instances in the applications pool and are executed |
in thread pool, asynchronous applications |
are designed to handle multiple connections |
simultaneously. |
|
These applications live as long as their reference |
counter is not 0. Once reference counter |
goes to 0 the application is destroyed and automatically |
unmounted from the applications pool. |
|
So in order to keep asynchronous application alive |
you need to do one of the following: |
|
1. Keep a persistent `intrusive_ptr` smart pointer |
pointer on the application, for example |
in your `main()` function. |
|
This is suitable for long running applications that |
exist all the time the service is running. |
|
2. Make sure that you have event handlers that hold |
a smart pointer and waiting for the event. |
|
This is usually done by passing `intrusive_ptr` withing |
the event handler. |
|
Such method is suitable for temporary |
applications that may represent for example |
different information channels like chat rooms |
that may be created or destroyed |
at some point. |
|
When you have application hierarchy |