• No results found

SIP Servlet Concurrency

In document SIP Servlet Specification, version 2.0 (Page 167-170)

16 Container Functions

16.3 SIP Servlet Concurrency

Multiple Servlets executing at the same time may have active access to shared resources like the SipSession and SipApplicationSession objects. These resources may also be accessed concurrently from ServletTimer objects, other Java EE modules in a converged Java EE application and also by the SIP Servlet Container at the same time. Operations (e.g.: updating values of session attributes) carried out by different threads on these objects can create concurrency issues, including deadlock, for some applications. This section explains ways to develop portable applications without concurrency issues.

16.3.1 Specifying Concurrency Mode

A SIP Servlet application can specify the required level of concurrency control the container should apply while executing application in the SipApplication annotation or in the

deployment descriptor. This specification support two values for the ConcurrencyMode enum. They are VENDORSPECIFIC and APPLICATIONSESSION. Here is an example of a servlet specifying the concurrency mode.

package com.example;

import javax.servlet.sip.SipServlet;

@SipApplication (name = “Foo”, concurrencyMode = ConcurrencyMode.APPLICATIONSESSION)

Table 16-1 Concurrency Modes

VENDORSPECIFIC Indicate that container can choose any concurrency level it deem appropriate. The level of guarantee of thread safety is determined by the SIP Servlet Container. This is the default

APPLICATIONSESSION Indicate that the container performs concurrency control at the level of application session. It make sure that two messages belonging to the same application session are never processed simultaneously. It also make sure various timer tasks or internal threads managed by the container that access the application session are not executed at the same time.

16.3.2 Executing tasks asynchronously

Concurrency Utilities for Java EE specification explains how an application can obtain

Concurrency Utilities in an enterprise server environment. A SIP servlet container use these utilities to execute asynchronous tasks and develop thread safe applications.

To enable this, a SIP servlet container exposes one or more ManagedExecutorService and ManagedScheduledExecutorService objects that execute submitted tasks in a thread pool managed by the container. While executing the tasks, container make sure that concurrency control specified by the application is maintained.

When a servlet (or any other part of the application) submit a task using this

ManagedExecutorService or ManagedScheduledExecutorService, apart from the context information specified in the Concurrency Utilities for EE specification, the active application session will also be passed as the context information. The active application session is the one responsible for the execution of the thread where application logic is running. Some examples are application session of the SipServletMessage that triggered servlet execution, application session of the executing ServletTimer, relevant application session of the application listener, application session of the ConvergedHttpSession of the HTTP servlet etc. If the task is submitted from a thread where no application session is active, then application can use the mechanism specified in the next session for specifying an application session as the context.

16.3.2.1 Specifying Application Session Programmatically

A thread might want to submit the task with a different application session as the context than the one active when the task is submitted. In this case, the application is expected to create a contextual object proxy using a ContextService for submitting the task. The application can then specify an application session of its choice as the context using one of the following execution properties.

z javax.servlet.sip.ApplicationSessionKey : Specify SIP application key

z javax.servlet.sip.ApplicationSessionId : Specify application session ID. To avoid concurrency issues, applications are required to submit asynchronous tasks whenever they want to use an application session different from the active application session. This rule applies for all kinds of application components, be it, SIP Servlets, HTTP Servlets, other Java EE components, Servlet Timers, asynchronous tasks etc.

If an application specifies both javax.servlet.sip.ApplicationSessionKey and javax.servlet.sip.ApplicationSessionId then

S I P S e r v l e t C o n c u r r e n c y

specified by either javax.servlet.sip.ApplicationSessionKey or

javax.servlet.sip.ApplicationSessionId is invalid or cannot be found then the container would abort the execution of the task and the ManagedTaskListener.taskAborted will be called with an AbortedException.

16.3.2.2 Impact on ApplicationSession Invalidation.

If an application invalidates the application session by

SipApplicationSession.invalidate() after the task has been submitted, then the container will invoke Future.cancel(false).

16.3.2.3 Example Usage 1. Submitting a task with active

SipApplicationSession Context.

@SipServlet

public class FooPOJO{

@Resource(name="concurrent/SipExecutor") ManagedExecutorService mes;

@Invite

protected void onInvite(SipServletRequest req) {

// Create a task instance. MySipTask implements Callable. MySipTask sipTask = new MySipTask();

// Submit the task to the ManagedExecutorService Future sipFuture = mes.submit(sipTask);

} }

16.3.2.4 Example Usage 2. Scheduling a task with a different

SipApplicationSession Context.

@SipServlet

public class FooPOJO{

@Resource(name="concurrent/SipScheduledExecutor") ManagedScheduledExecutorService mses;

@Resource(name="concurrent/AllContexts") ContextService ctxSvc;

@Invite

protected void onInvite(SipServletRequest req) {

SipApplicationSession sas = //...lookup using SipSessionsUtil

// Set any custom context data through execution properties Map<String, String> execProps = new HashMap<>();

execProps.put("javax.servlet.sip.ApplicationSessionId", sas.getId());

// Create a task instance. MySipTask implements Callable. MySipTask sipTask = new MySipTask();

Callable task = ctxSvc.createContextualProxy (sipTask, execProps, Callable.class);

// Submit the task to the ManagedScheduledExecutorService Future sipFuture = mses.submit(task);

} }

16.3.2.5 Default Managed Objects

SIP servlet container must provide a preconfigured, default

ManagedExecutorService

and

ManagedScheduledExecutorService

objects for use by application components

under the JNDI name

java:comp/ManagedSipExecutorService

and

java:comp/ManagedScheduledSipExecutorService

respectively. The types of

contexts to be propagated by this default

ManagedExecutorService

must include

naming context, classloader, and security information apart from application session

In document SIP Servlet Specification, version 2.0 (Page 167-170)