The following sections describe how to configure a WebLogic SIP Server domain to use an Oracle or MySQL RDBMS with the data tier cluster, in order to conserve RAM:
WebLogic SIP Server enables you to store long-lived call state data in an Oracle or MySQL RDBMS in order to conserve RAM. When you enable RDBMS persistence, by default the data tier persists a call state’s data to the RDBMS after the call dialog has been established, and at subsequent dialog boundaries, retrieving or deleting the persisted call state data as necessary to modify or remove the call state.
BEA also provides an API for application designers to provide “hints” as to when the data tier should persist call state data. These hints can be used to persist call state data to the RDBMS more frequently, or to disable persistence for certain calls. See
Note that WebLogic SIP Server only uses the RDBMS to supplement the data tier’s in-memory replication functionality. To improve latency performance when using an RDBMS, the data tier maintains SIP timers in memory, along with call states being actively modified (for example, in response to a new call being set up). Call states are automatically persisted only after a dialog has been established and a call is in progress, at subsequent dialog boundaries, or in response to persistence hints added by the application developer.
When used in conjunction with an RDBMS, the data tier selects one replica server instance to process all call state writes (or deletes) to the database. Any available replica can be used to retrieve call states from the persistent store as necessary for subsequent reads.
RDBMS call state storage can be used in combination with an engine tier cache, if your domain uses a SIP-aware load balancer to manage connections to the engine tier. See Using the Engine Tier Cache.
Enable RDBMS call state storage only when all of the following criteria are met:
The latency requirement, in particular, must be well understood before choosing to store call state data in an RDBMS. The RDBMS call state storage option measurably increases latency for SIP message processing, as compared to using a data tier cluster. If your system must handle a large number of short-lived SIP transactions with brief response times, BEA recommends storing all call state data in the data tier.
Note: | RDBMS persistence is designed only to reduce the RAM requirements in the data tier for large, long-lived call states. The persisted data cannot be used to restore a failed data tier partition or replica. |
In order to use the RDBMS call state storage feature, your WebLogic SIP Server domain must include the necessary JDBC configuration, SIP Servlet container configuration, and a database having the schema required to store the call state. You can automate much of the required configuration by using the Configuration Wizard to set up a new domain with the RDBMS call state template. See Using the Configuration Wizard RDBMS Store Template.
If you have an existing WebLogic SIP Server domain, or you want to configure the RDBMS store on your own, see Configuring RDBMS Call State Storage by Hand for instructions to configure JDBC and WebLogic SIP Server to use an RDBMS store.
The Configuration Wizard provides a simple template that helps you easily begin using and testing the RDBMS call state store. Follow these steps to create a new domain from the template:
cd ~/bea/sipserver30 /common/bin
./config.sh
replicateddomain.jar
, and click OK.The template creates a new domain with two engine tier servers in a cluster, two data tier servers in a cluster, and an Administration Server (AdminServer). The engine tier cluster includes the following resources and configuration:
wlss.callstate.datasource
, required for storing long-lived call state data. Note that you must modify this configuration to configure the datasource for your own RDBMS server. See Modify the JDBC Datasource Connection Information.After installing the new domain, modify the template JDBC datasource to include connection information for your RDBMS server:
To change an existing WebLogic SIP Server domain to store call state data in an Oracle or MySQL RDBMS, you must configure the required JDBC datasource, edit the WebLogic SIP Server configuration, and add the required schema to your database. Follow the instructions in the sections below to configure an Oracle Database.
Follow these steps to create the required JDBC resources in your domain:
Follow these steps to configure the WebLogic SIP Server persistence options to use an RDBMS call state store:
WebLogic SIP Server includes a SQL script, callstate.sql
, that you can use to create the tables necessary for storing call state information. The script is installed to the user_staged_config
subdirectory of the domain directory when you configure a replicated domain using the Configuration Wizard. The script is also available in the WLSS_HOME/common/templates/scripts/db/oracle
directory.
The contents of the callstate.sql
SQL script are shown in Listing 4-1.
drop table callstate;
create table callstate (
key1 int,
key2 int,
bytes blob default empty_blob(),
constraint pk_callstate primary key (key1, key2)
);
Follow these steps to execute the script commands using SQL*Plus:
utils
directory, in which the SQL Script is stored:cd ~/bea/sipserver30/common/templates/scripts/db/oracle
sqlplus username/password@connect_identifier
where connect_identifier
connects to the database identified in the JDBC connection pool.
callstate.sql
:START callstate.sql
EXIT
WebLogic SIP Server provides a simple API to provide “hints” as to when the data tier should persist call state data. You can use the API to disable persistence for specific calls or SIP requests, or to persist data more frequently than the default setting (at SIP dialog boundaries).
To use the API, simply obtain a WlssSipApplicationSession
instance and use the setPersist
method to enable or disable persistence. Note that you can enable or disable persistence either to an RDBMS store, or to as geographically-redundant WebLogic SIP Server installation (see Configuring Geographically- Redundant Installations).
For example, some SIP-aware load balancing products use the SIP OPTIONS message to determine if a SIP Server is active. To avoid persisting these messages to an RDBMS and to a geographically-redundant site, a Servlet might implement a doOptions
method to echo the request and turn off persistence for the message, as shown in Listing 4-2.
protected void doOptions(SipServletRequest req) throws IOException {
WlssSipApplicationSession session =
(WlssSipApplicationSession) req.getApplicationSession();
session.setPersist(WlssSipApplicationSession.PersistenceType.DATABASE,
false);
session.setPersist(WlssSipApplicationSession.PersistenceType.GEO_REDUNDANCY, false);
req.createResponse(200).send();
}