Obtaining a Reference to SipServletSnmpTrapRuntimeMBean
4-2 Oracle WebLogic Server SIP Container Developer’s Guide
To obtain the greatest advantage from the WebLogic Server architecture, construct your application modules according to the SIP Servlet and Java EE API specifications.
Avoid application designs that require creating new threads in server-side modules such as SIP Servlets:
■
The SIP Servlet container automatically locks the associated call state when invoking the doxxx method of a SIP Servlet. If the doxxx method spawns
additional threads or accesses a different call state before returning control, deadlock scenarios and lost updates to session data can occur.
■
Applications that create their own threads do not scale well. Threads in the JVM are a limited resource that must be allocated thoughtfully. Your applications may
break or cause poor WebLogic Server performance when the server load increases. Problems such as deadlocks and thread starvation may not appear until the
application is under a heavy load.
■
Multithreaded modules are complex and difficult to debug. Interactions between application-generated threads and WebLogic Server threads are especially difficult
to anticipate and analyze.
■
The WlssSipApplicationSession.doAction method, described in Use
setAttribute to Modify Session Data in “No-Call” Scope , does not provide
synchronization for spawned Java threads. Any threads created within doAction can execute another doAction on the same
WlssSipApplicationSession. Similarly, main threads that use doAction to access a different wlssSipApplicationSession can lead to deadlocks,
because the container automatically locks main threads when processing incoming SIP messages.
Use setAttribute to Modify Session Data in “No-Call” Scope describes a potential deadlock situation.