|
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
public interface CiscoSynchronousObserver
The Cisco JTAPI implementation is designed to allow applications to invoke blocking JTAPI methods
such as Call.connect()
and TerminalConnection.answer()
from within
their observer callbacks. This means that applications are not subject to the restrictions
imposed by the JTAPI specification, which cautions applications against using JTAPI methods from
within observer callbacks.
Normally, when an application adds a new observer to a JTAPI object, the Cisco JTAPI
implementation creates an event queue and an accompanying worker thread to service the new
observer. If the same observer is added to another object, its queue and thread are reused; in
effect, every unique observer object has a single queue and worker thread. As noted, the
advantage of this arrangement is that an application may invoke blocking JTAPI methods from
within its observer callback. A subtle disadvantage, however, is that accessor methods such as
Call.getConnections()
and Connection.getState()
may not return results
that are consistent with events when invoked from within the observer callback.
For example, suppose that an application creates and connects a call from address "A" to address
"B." If the application is observing address "A", it might reasonably expect that when it
receives the CallActiveEv
, the state of the call will be Call.ACTIVE
.
This is not necessarily true, because the worker thread that delivers events to the application
is decoupled from the internal JTAPI thread that updates object states. In fact, if "B" rejects
the call from "A," the call object might be in either the Call.ACTIVE
state or the
Call.INVALID
state, depending on the exact moment at which the worker thread
delivers the CallActiveEv
.
Many applications will not be adversely affected by this asychronous behavior. Applications that
would benefit from a coherent call model during observer callbacks, however, can selectively
disable the queueing logic of the Cisco JTAPI implementation. Applications that implement the
CiscoSynchronousObserver
interface on their observer objects declare that they want
events to be delivered synchronously to its observers. Events delivered to synchronous observers
will match the states of the call model objects queried from within the observer callback.
Objects that implement the CiscoSynchronousObserver
interface may not invoke
blocking JTAPI methods from within their event callbacks. The consequences of doing so are
unpredictable, and may include deadlocking the JTAPI implementation. On the other hand, you may
safely use the accessor methods of any JTAPI object, such as Call.getConnections()
or Connection.getState()
.
|
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |