Requirements and Best Practices for SIP Applications 4-3
4.5 All Session Data Must Be Serializable
To support in-memory replication of SIP application call states, you must ensure that all objects stored in the SIP Servlet session are serializable. Every field in an object
must be serializable or transient in order for the object to be considered serializable. If the Servlet uses a combination of serializable and non-serializable objects, WebLogic
Server cannot replicate the session state of the non-serializable objects.
4.6 Use setAttribute to Modify Session Data in “No-Call” Scope
The SIP Servlet container automatically locks the associated call state when invoking the doxxx method of a SIP Servlet. However, applications may also attempt to modify
session data in no-call scope. No-call scope refers to the context where call state data is modified outside the scope of a normal doxxx method. For example, data is
modified in no-call scope when an HTTP Servlet attempts to modify SIP session data, or when a SIP Servlet attempts to modify a call state other than the one that the
container locked before invoking the Servlet.
Applications must always use the SIP Sessions setAttribute method to change attributes in no-call scope. Likewise, use removeAttribute to remove an attribute
from a session object. Each time setAttributeremoveAttribute is used to update session data, the SIP Servlet container obtains and releases a lock on the
associated call state. The methods enqueue the object for updating, and return control immediately. This ensures that only one application modifies the data at a time, and
also ensures that your changes are replicated across SIP data tier nodes in a cluster.
If you use other set methods to change objects within a session, WebLogic Server cannot replicate those changes.
Note that the WebLogic Server container does not persist changes to a call state attribute that are made after calling setAttribute. For example, in the following
code sample the setAttribute call immediately modifies the call state, but the subsequent call to modifyState does not:
Foo foo = new Foo..; appSession.setAttributename, foo; This persists the call state.
foo.modifyState; This change is not persisted.
Instead, ensure that your Servlet code modifies the call state attribute value before calling setAttribute, as in:
Foo foo = new Foo..; foo.modifyState;
appSession.setAttributename, foo;
Also, keep in mind that the SIP Servlet container obtains a lock to the call state for each individual setAttribute call. For example, when executing the following code in an
HTTP Servlet, the SIP Servlet container obtains and releases a lock on the call state lock twice:
appSess.setAttributefoo1, bar2; appSess.setAttributefoo2, bar2;
This locking behavior ensures that only one thread modifies a call state at any given time. However, another process could potentially modify the call state between
sequential updates. The following code is not considered thread safe when done no-call state:
Integer oldValue = appSession.getAttributecounter; Integer newValue = incrementCounteroldValue;