Shared contexts are those contexts above the session contexts. These contexts
are potentially accessed from multiple threads corresponding to different
user requests at the same time, so some considerations have to be taken into
account:
- Read-only data: only place the read-only data in shared contexts.
There are no concurrency problems when accessing read-only data, so this is
perfectly safe.
- Read-write data: in the case where data needs to be updated during
the execution of the application, consider the following two problems:
- Concurrency: because multiple threads can access the same field
in a shared context, there are concurrency problems if the data are not accessed
with proper synchronization safeguards.
- Server clustering: when more than one server clone is used, there
is a copy of the shared context tree for each JVM where the application runs.
If a user's request requires that a data field in a shared context to be updated,
its new value will only be visible to the users whose session is located in
the same server where the original request was executed. This is probably
not what is expected, as shared values are designed to be transparently accessed
by multiple users independent of the clone they are running on. Consider for
example the case of a branch-level unique receipt counter that gets incremented
every time a receipt gets printed. That could be in principle located in a
branch context, but then two users of the same branch whose session runs in
different clones will manipulate totally independent receipt counter values.
Both the concurrency and clustering problem can be solved by using a safe
persistence-based mechanism to manipulate all read-write shared data. A simple,
ad-hoc approach is to use a custom database table to access these values.
There is also a more generic way supported by BTT since version 5.2: the shared
data can be set up so that they are automatically persisted by the framework.
This is known as the CHA (Context Hierarchy Area), and since version 7.0,
there is a high level of flexibility in the way that this can be configured,
either through entity bean persistence, shared memory or any other user-provided
mechanism.