Servlets Must Be Non-Blocking

4-4 Oracle WebLogic Server SIP Container Developer’s Guide appSession.setAttributecounter, newValue; To make the above code thread safe, you must enclose it using the wlssAppSession.doAction method, which ensures that all modifications made to the call state are performed within a single transaction lock, as in: wlssAppSession.doActionnew WlssAction { public Object run throws Exception { Integer oldValue = appSession.getAttributecounter; Integer newValue = incrementCounteroldValue; appSession.setAttributecounter, newValue; return null; } }; Finally, be careful to avoid deadlock situations when locking call states in a doSipMethod call, such as doInvite. Keep in mind that the WebLogic Server container has already locked the call state when the instructions of a doSipMethod are executed. If your application code attempts to access the current call state from within such a method for example, by accessing a session that is stored within a data structure or attribute, the lock ordering results in a deadlock. Example 4–1 shows an example that can result in a deadlock. If the code is executed by the container for a call associated with callAppSession, the locking order is reversed and the attempt to obtain the session with getApplicationSessioncallId causes a deadlock. Example 4–1 Session Access Resulting in a Deadlock WlssSipApplicationSession confAppSession = WlssSipApplicationSession appSession; confAppSession.doActionnew WlssAction { confAppSession is locked public Object run throws Exception { String callIds = confAppSession.getAttributecallIds; for each callId in callIds { callAppSess = Session.getApplicationSessioncallId; callAppSession is locked attributeStr += callAppSess.getAttributesomeattrib; } confAppSession.setAttributeattrib, attributeStr; } } See Section 6.3.1, Modifying the SipApplicationSession for more information about using the com.bea.wcp.sip.WlssAction interface.

4.7 send Calls Are Buffered

If your SIP Servlet calls the send method within a SIP request method such as doInvite, doAck, doNotify, and so forth, keep in mind that the WebLogic Server container buffers all send calls and transmits them in order after the SIP method returns. Applications cannot rely on send calls to be transmitted immediately as they are called. Caution: Applications must not wait or sleep after a call to send because the request or response is not transmitted until control returns to the SIP Servlet container.