Oracle Server E10293-02 Benutzerhandbuch
Storing Data in Application Sessions
4-2 Oracle Communication and Mobility Server Developer’s Guide
Storing Data in Application Sessions
All data that must persist for a session must be stored in the SIP Application Session
explicitly and must be serializable.
explicitly and must be serializable.
Avoiding Static Data
As a corollary, to the previous recommendation, avoid using static variables in an
application, instead use standard J2EE mechanisms such as EJB or database storage to
achieve persistent storage of data that can be made available to another cluster node in
the event of a failure.
application, instead use standard J2EE mechanisms such as EJB or database storage to
achieve persistent storage of data that can be made available to another cluster node in
the event of a failure.
Avoiding Blocking Calls
All blocking calls as part of the invocation of a SIP Servlet application should be
avoided. Blocking calls include Synchronous Remote procedure calls and synchronous
database calls.
avoided. Blocking calls include Synchronous Remote procedure calls and synchronous
database calls.
Invalidating the SipApplicationSession and SIPSession
Remember to invalidate the SipApplicationSession in order to free up memory as soon
as possible when the application has finished. For individual SIP Sessions, you should
invalidate them as soon as they are finished as well. Make sure there are no active SIP
Sessions when you invalidate a SIP Application Session as the owned SIP Sessions will
be invalidated as well.
as possible when the application has finished. For individual SIP Sessions, you should
invalidate them as soon as they are finished as well. Make sure there are no active SIP
Sessions when you invalidate a SIP Application Session as the owned SIP Sessions will
be invalidated as well.
Monitoring the Memory Usage
Monitor the memory usage for the data you want to store in session objects. Make sure
there is sufficient memory for the number of sessions created before the sessions time
out.
there is sufficient memory for the number of sessions created before the sessions time
out.
Avoiding Storing Shared Resources in Sessions
Objects that are stored in the session objects will not be released until the session times
out (or is invalidated). If you hold any shared resources that have to be explicitly
released to the pool before they can be reused (such as a JDBC connection), then these
resources may never be returned to the pool properly and can never be reused.
out (or is invalidated). If you hold any shared resources that have to be explicitly
released to the pool before they can be reused (such as a JDBC connection), then these
resources may never be returned to the pool properly and can never be reused.
Avoiding Creating Threads
Use the available mechanisms to create an event driven model for your application
instead of creating threads to perform work outside of the activation model for the
containers.
instead of creating threads to perform work outside of the activation model for the
containers.
Creating B2BUA Applications
For B2BUA Applications, use the createRequest that clones the relevant fields of the
original request:
original request:
SipFactory.createRequest(SipServletRequest
origRequest,
boolean sameCallId)