Exploit the Browser Cache

[jri]

To reduce network round-trips the Webclient should maintain an entity cache for topics and associations. The cache could be validated by the entities modified timestamps (see #386). To do so, the Webclient must set the If-Modified-Since header in at least two GET requests:

/core/topic/{id}
/core/association/{id}

The server in turn must compare the request's timestamp to the one stored in the DB and must respond with 304 (Not Modified) when indicated.

An ETag-based approach could also be considered.

The timestamps (resp. Etags) would also serve as the basis for the detection of edit conflicts (see #479).

[jri]

New Core Event PRE_PROCESS_REQUEST (#480, #478).

Fired before a request is processed. That is *before* a possible resource method is invoked.
This allows a plugin e.g. to abort request processing in case a pre-condition is not met (as stated e.g. by the If-Modified-Since or If-Unmodified-Since headers).

New listener interface:

de.deepamehta.core.service.event.PreProcessRequestListener?

Listener method:

void preProcessRequest(ContainerRequest? request)

Note: ContainerRequest? is a Jersey-specific class
(com.sun.jersey.spi.container.ContainerRequest?).
We should remove the Jersey dependency and move to JAX-RS 2.0 instead.

Close ticket 480.
See ticket 478.

Changeset: 0d1cf5baded3320d0520e32fd5cc1674ce77eb27

[jri]

New plugin: DeepaMehta 4 Caching (#478).

If a If-Modified-Since header is present in a GET request a 304 (Not Modified) response is possibly send.
In this case the topic/association is not fecthed from the DB. Only the timestamp is.

See ticket 478.

Changeset: 372907375787b099f0fceca1dd57242864a8d57d

[jri]

Add 2 new plugins to reactor build (#386, #478).

DeepaMehta 4 Time
DeepaMehta 4 Caching

See ticket 386.
See ticket 478.

Changeset: b9c5fa2584ff000a6560df1e92ce97b0312d2e27

[jri]

Caching plugin: set Cache-Control header (#478).

If the response contains a single DeepaMehtaObject? the response's freshness lifetime is set to zero. That is the Last-Modified response header is set to max-age=0. This enforces the browser to revalidate its cache for every request (typically by sending a conditional GET request).

See ticket 478.

Changeset: 41c1f0bc0f1d89855494e355fc033ed591b8a188

[jri]

There is a bug in the Webclient module: see #488

[jri]

Caching: fix conditional PUT request (#386, #478).

Topics/associations contained in a Directives object are enriched with their modification timestamps.
As a consequence the Caching module uses the up-to-date modification timestamp when constructing a subsequent PUT request.

See ticket 386.
See ticket 478.

Changeset: 4528ffa5017160f17e675cfea16545e563027081

[jri]

There is a bug: once the user's login status changes the browser cache still holds the old permissions that are cached along with the topics/associations.
As a consequence e.g. after login a topic is not editable as long as the browser cache is reset (resp. reload is pressed several times).

Solution: the Access Control module must *not* deliver the permissions along with the topic/association (in the composite value). Instead the Webclient must request the permissions separately via the Access Control service.
To reduce requests the Access Control module could maintain its own cache for the permission information, and invalidate it once the user's login status changes.

UPDATE: this issue got its own ticket (#489).

[jri]

Access Control: fix permission cache (#489, #478).

The Access Control module does *not* deliver the permissions along with the topic/association (in the composite value). Instead the Webclient requests the permissions separately via the Access Control service.

To reduce the number of requests the Access Control module maintains its own client-side cache for the permission information, and invalidates it once the user's login status changes.

This fixes the bug of stale permissions (due to browser caching) once the user's login status changes.

=> For the first time since introduction of timestamps, edit conflict detection, and browser caching DM should be in a good shape now. Please give it a try and report any problems.

Access Control API has 1 new method:

• Server-side: Permissions getAssociationPermissions(long assocId)
• RESTful: GET /accesscontrol/association/{id}
• Cliet-side: dm4c.restc.get_association_permissions(assoc_id)

Close ticket 489.
See ticket 478.

Changeset: b9170f2d85ab6dcc108af1e2497dd6c94b869af4

[jri]

Time and Caching fixes (#386, #478, #479).

FIXES

• Browser caching is enabled also for topics/associations which have no timestamp. 0 assumed as default (Jan 1, 1970).
• Edit conflict detection works also for topics/associations which have no timestamp.

CHANGES

Time plugin:

• for topics/associations send to the client their creation timestamp is available in the composite value as well (besides the modification timestamp).
• the time API's timestamp getter methods return 0 as default in case no timestamp is stored (before -1 has been returned).
• the Last-Modified response header is also set for a default timestamp value (0).

Caching plugin:

• a request's precondiction is also checked for a default timestamp value (0).

See #386.
See #478.
See #479.

Changeset: 1b5bbdb7c6b963915168f5a7c69e6ccb8a13d427

[Malte]

Please consider also setting the max-age header for all static resources (scripts, images, stylesheets) to some value so we can exploit the browser cache even more optimal.

[jri]

Thanks, Malte, for the hint. I created a separate ticket for that: #501.

This ticket is regarded as complete now.