View source | View content page | Page history | Printable version   
Toolbox
Main Page
Upload file
What links here
Recent changes
Help

PDF Books
Show collection (0 pages)
Collections help

Search

Projects:ApplicationScoped ADCS/Technical Specifications

Contents

Introduction

ApplicationDictionaryCachedStructures (ADCS) caches Application Dictionary components, it is mainly used from FormInitializationComponent to improve performance by reducing the DB reads. Currently is SessionScoped which means there is an instance for each backoffice session.

Depending on the usage (this cache is lazy) the amount of heap space it can retain can increase to several MB. In instances with many concurrent sessions, the total retained size can hugely increase.

Measurements

The size of this cache significantly varies depending on the actual application usage. Checking in some real customers the retained sizes per instance vary from ~700KB to ~45MB, being in average ~13MB. Which is more than 1GB per 100 concurrent sessions.

The expected improvement is to reduce this per session size to a single ADCS instance which will be bigger than per session average (expected to be less than 100MB in any case) but will scale much better.

Application Scoped

To solve this problem and make much more scalable in terms of memory the increase of concurrent sessions, the proposal is to move from session to application scoped this cache. In this manner, a single ADCS instance would serve all active sessions.

Considerations

In order to do this movement, two main factors need to be taken into consideration.

Cached data

Data that is cached in ADCS must be globally valid, this is, it cannot contain any session specific information such as language, session role, etc.

In this regards, the main refactor required to be done is in ComboTableData cache, where current session's list of accessible clients and organizations where cached. Now, this must be resolved when the actual query is executed, so the new key for this cache will be just the field the combo is for so that possible validations and window access level can also be cached.

Concurrency

The other main concern is about concurrency. Being ADCS session scoped the concurrecy in this cache was really low as the chances of multiple threads per session are reduced. Now that the scope is going to be application, the probability of concurrent use of this cache significantly increases.

This implies some refactors require to be done:

The following graph represents the ADCS invocation flow:

ADCS invokation flows.svg

Retrieved from "http://wiki.openbravo.com/wiki/Projects:ApplicationScoped_ADCS/Technical_Specifications"

This page has been accessed 146 times. This page was last modified on 17 January 2017, at 08:40. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.