|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
public interface ApplicationToMonitorInterface
This interface represents the Java Application-to-Transaction Monitor Interface (JATMI) that provides connectivity between WebLogic Server and Tuxedo Services.
Field Summary | |
---|---|
static int |
TPABSOLUTE
Internal flag |
static int |
TPACK
Request acknowledgment of tpnotify |
static int |
TPAPPAUTH
System and application authentication |
static int |
TPCONV
Internal flag |
static int |
TPGETANY
Get any reply |
static int |
TPNOAUTH
Authentication not required |
static int |
TPNOBLOCK
Do not block |
static int |
TPNOCHANGE
Do not allow buffer type to change (not used in JATMI) |
static int |
TPNOREPLY
No reply expected |
static int |
TPNOTIME
Do not time out this call |
static int |
TPNOTRAN
Do not execute inside current transaction |
static int |
TPRECVONLY
Set conversation to read only mode |
static int |
TPRMICALL
Indicates an outbound RMI/IIOP call |
static int |
TPSENDONLY
Set conversation to send only mode |
static int |
TPSIGRSTRT
Restart on signal (not used in JATMI) |
static int |
TPSYSAUTH
System password authentication required |
static int |
TPTRAN
Execute in a trasaction |
static int |
TPUNKAUTH
Unknown authentication level |
Method Summary | |
---|---|
CallDescriptor |
tpacall(java.lang.String svc,
TypedBuffer data,
int flags)
Sends a deferred asyncronous request message to a Tuxedo service. |
CallDescriptor |
tpacall(java.lang.String svc,
TypedBuffer data,
int flags,
TpacallAsyncReply callBack)
Sends an asyncronous request message to a Tuxedo service. |
Reply |
tpcall(java.lang.String svc,
TypedBuffer data,
int flags)
Sends a request and synchronously awaits for the reply. |
void |
tpcancel(CallDescriptor cd,
int flags)
Cancels a call descriptor for outstanding reply. |
Conversation |
tpconnect(java.lang.String svc,
TypedBuffer data,
int flags)
Establishes a half-duplex connection to a conversational service, svc . |
DequeueReply |
tpdequeue(java.lang.String qspace,
java.lang.String qname,
byte[] msgid,
byte[] corrid,
boolean doWait,
boolean doPeek,
int flags)
Removes a message for processing from the queue named by qname in the qspace queue space. |
DequeueReply |
tpdequeue(java.lang.String qspace,
java.lang.String qname,
int flags)
Removes a message for processing from the queue named by qname in the qspace queue space using the following parameters: msgid and corrid set to null. |
byte[] |
tpenqueue(java.lang.String qspace,
java.lang.String qname,
EnqueueRequest ctl,
TypedBuffer data,
int flags)
Stores a message on the queue named by qname in the qspace queue space. |
Reply |
tpgetrply(CallDescriptor cd,
int flags)
Returns a reply using the call descriptor returned by a deferred tpacall . |
void |
tpsprio(int prio,
int flags)
Sets the priority for the next request sent or forwarded by the current thread in the current context. |
void |
tpterm()
Dissasociates an object from a Tuxedo session. |
Field Detail |
---|
static final int TPNOBLOCK
static final int TPSIGRSTRT
static final int TPNOREPLY
static final int TPNOTRAN
static final int TPTRAN
static final int TPNOTIME
static final int TPABSOLUTE
static final int TPGETANY
static final int TPNOCHANGE
static final int TPCONV
static final int TPSENDONLY
static final int TPRECVONLY
static final int TPACK
static final int TPRMICALL
static final int TPUNKAUTH
static final int TPNOAUTH
static final int TPSYSAUTH
static final int TPAPPAUTH
Method Detail |
---|
CallDescriptor tpacall(java.lang.String svc, TypedBuffer data, int flags) throws TPException
tpacall
service call sends a
request to a Tuxedo service and immediately returns from the call. The service
specified (svc
) must be advertised by your Tuxedo application. Upon successful
completion of the call, tpacall
returns an object that serves
as a descriptor. The calling thread is now available to perform other tasks.
You can use the call descriptor to get the correct reply for the sent request
using tpgetreply
or cancel an outstanding message reply using
tpcancel
.
A tpacall
message request is sent with a message priority of 50.
The type and sub-type of data
must match one of the types and
sub-types recognized by svc
. If data
is non-null,
it must point to an object that implements the TypedBuffer interface.
If data
is null, a request is sent with no data portion.
If tpacall
is in a transaction, you must receive the reply
using tpgetreply
before the transaction can commit. You can
not use tpcancel
to cancel a call descriptor associated
with a transaction.
svc
- The name of the Tuxedo servicedata
- Pointer to the data buffer; null specifies no data sentflags
- svc
is invoked, the call does not becoome part of the
caller's transaction. If svc
belongs to a server that does not
support transactions, this flag must be set when the caller is
in transaction mode. Note that svc
may still be invoked in
transaction mode but it will not be the same transaction: a svc
may
have a configuration attribute that it is automatically invoked
in transaction mode. A caller in transaction mode that sets this flag
is still subject to the transaction timeout (and no other). If a
service fails that was invoked with this flag, the caller's
transaction is not affected.
tpgetreply
or
tpcancel
.TPException
- Returns a TPException indicating the error condition.
tperrno
is set to one of the following values:svc
is null
or flags are invalid.
svc
does not exist or is a
conversational service.
data
does not match the
type and sub-type expected by svc
.
svc
belongs to a server that does not support transactions
and TPNOTRAN was not set.
tpacall
with TPNOTRAN,
TPNOBLOCK, and TPNOREPLY set.tpacall
was called improperly.
tpacall
returned successfully.
CallDescriptor tpacall(java.lang.String svc, TypedBuffer data, int flags, TpacallAsyncReply callBack) throws TPException
tpacall
service call sends a request
to a Tuxedo service and releases the thread resource that performed
the call to the thread pool. This allows a very large number of outstanding
requests to be serviced with a much smaller number of threads. The service specified
(svc
) must be advertised by your Tuxedo application. Upon successful
completion of the call, asynchronous tpacall
returns an object that
serves as a descriptor. The calling thread is now available to perform other tasks.
You can use the call descriptor to identify the correct message reply from TpacallAsynchReply
for a sent message request or cancel an outstanding message reply using tpcancel
.
You can not use the call descriptor to invoke tpgetreply().
callBack
- The object to invoke when the service reply is ready. If the original request succeeded,
the TpacallAsynchReply.sucess
method returns the reply from the service. If the original
request failed, the TpacallAsynchReply.failure
method returns a failure code. If null,
the request becomes a deferred asyncronous tpacall
.svc
- The name of the Tuxedo servicedata
- Pointer to the data buffer; null specifies no data sentflags
- svc
is invoked, the call does not becoome part of the
caller's transaction. If svc
belongs to a server that does not
support transactions, this flag must be set when the caller is
in transaction mode. Note that svc
may still be invoked in
transaction mode but it will not be the same transaction: a svc
may
have a configuration attribute that it is automatically invoked
in transaction mode. A caller in transaction mode that sets this flag
is still subject to the transaction timeout (and no other). If a
service fails that was invoked with this flag, the caller's
transaction is not affected.
TPException
- Returns a TPException indicating the error condition.
If an exception is thrown by this method the callBack will not
be invoked.
tperrno
is set to one of the following values:svc
is null
or flags are invalid.
svc
does not exist or is a
conversational service.
data
does not match the
type and sub-type expected by svc
.
svc
belongs to a server that does not support transactions
and TPNOTRAN was not set.
tpacall
with TPNOTRAN,
TPNOBLOCK, and TPNOREPLY set.tpacall
was called improperly.
tpacall
returned successfully.void tpcancel(CallDescriptor cd, int flags) throws TPException
tpcancel
cancels a call descriptor, cd
, returned
by tpacall
. cd
is no longer valid and any reply received on
behalf of cd
is silently discarded. It is an error to cancel
a call descriptor associated with a transaction.
cd
- Call descriptor returned by a deferred or ansyncronous tpacall.flags
- Must be zero
TPExcpetion
- The following return codes may be thrown:pcancel
was called improperly.
TPException
Reply tpgetrply(CallDescriptor cd, int flags) throws TPException, TPReplyException
tpacall
.
tpgetreply
waits until the reply matching
the call descriptor, cd
arrives or a timeout occurs.Within any particular context of a multithreaded program:
tpgetrply(TPGETANY)
and tpgetrply
for a
specific handle cannot be issued concurrently.
tpgetrply(TPGETANY)
cannot be issued concurrently.
tpgetrply
call causes a violation of
either of these restrictions throws a TPException with errno
set to
TPEPROTO
.
tpgetrply
for different handles
tpgetrply(TPGETANY)
in a single context concurrently
with a call to tpgetrply, with or without TPGETANY
,
in a different context.
cd
- Call descriptor returned from deferred tpacall or null
if TPGETANY
flag is setflags
- The following is a list of valid flags:tpgetrply
ignores the
call descriptor, returns any reply available, and sets cd
in the replyrtn
object corresponding to the reply returned.
If no reply exists, the default behavior of tpgetrply
is to
wait for a reply to arrive.
tpgetrply
does not wait for the
reply to arrive. If the reply is available, then tpgetrply
returns a reply object that contains the
reply data from the service, the service return status, and the call
descriptor of the returned data. You should always check the return status
of the reply object to determine if the service returned successfully.
TPException
- Upon failure tpgetrply
throws TPException
to indicate the
error condition. tperrno in TPException will be set to one of the following
values:cd
or
flags
are invalid.
cd
points to an invalid descriptor.
tpacall
with TPNOTRAN,
TPNOBLOCK and TPNOREPLY set.
tpgetrply
was called improperly.
TPReplyException
- If there is a service failure (TPESVCFAIL or
TPSVCERROR) in which case the exception will also have reply
data from the service. However, unlike the tpcall
case, this
execption may also be thrown in any of the above TPException cases as well,
so that specific TPException return codes can be matched with the
request object returned from tpacall
. If TPReplyException is thrown
then it is on behalf of an outstanding request and that request is considered
to have completed with a failure.Reply tpcall(java.lang.String svc, TypedBuffer data, int flags) throws TPException, TPReplyException
tpcall
is the same as a deferred tpacall
immediately followed by tpgetrply
. tpcall
sends a
request to the service named by svc
. The
request is sent out at the priority defined for svc
unless overridden by
a previous call to tpsprio
. The type and sub-type of data must match
one of the types and sub-types recognized by svc
.
svc
- The name of the Tuxedo servicedata
- Pointer to the data buffer; null specifies no data sentflags
- The following is a list of valid flags:tpcall
- the function may block when waiting for the reply. When
TPNOBLOCK is not specified and a blocking condition exists, the
caller blocks until the condition subsides or a timeout occurs
(either transaction or blocking timeout).
tpcall
returns a reply object that contains the
reply data from the service and the service return status.
You should always check the return status
of the reply object to determine if the service returned successfully.
TPException
- Upon failure tpcall
sets tperrno in TPException to one of the
following values. Unless otherwise noted, failure does not affect
the caller's transaction, if one exists. svc
is null or
flags are invalid.
svc
because it does not exist, it is a
conversational service, or the name provided begins with "." - a dot.
svc
accepts.
svc
belongs to a server that does not support transactions
and TPNOTRAN was not set.
tpacall
with TPNOTRAN, TPNOBLOCK,
and TPNOREPLY set.
tpcall
was called improperly.
tpcall
returned successfully.
TPReplyException
- If there was a service failure (TPESVCFAIL or
TPSVCERROR), the exception will also have the reply data from the service.byte[] tpenqueue(java.lang.String qspace, java.lang.String qname, EnqueueRequest ctl, TypedBuffer data, int flags) throws TPException
When the message is intended for a BEA Tuxedo system server, the qname matches the name of a service provided by the server. The system provided server, TMQFORWARD(5), provides a default mechanism for dequeuing messages from the queue and forwarding them to servers that provide a service matching the queue name. If the originator expects a reply, then the reply to the forwarded service request is stored on the originator's queue, unless otherwise specified. The originator will dequeue the reply message at a subsequent time. Queues can also be used for a reliable message transfer mechanism between any pair of BEA Tuxedo system processes (clients and/or servers). In this case, the queue name does not match a service name but some agreed upon name for transferring the message.
If data is non-null, it must point to an object that implements the TypedBuffer interface. If data is null a message is queued with no data portion.
The message is queued at the priority defined for qspace unless overridden by a previous call to tpsprio().
If the caller is within a transaction and the TPNOTRAN flag is not set, the message is queued in transaction mode. This has the effect that if tpenqueue() returns successfully and the caller's transaction is committed successfully, then the message is guaranteed to be available subsequent to the transaction completing. If the caller's transaction is rolled back either explicitly or as the result of a transaction timeout or some communication error, then the message will be removed from the queue (that is, the placing of the message on the queue is also rolled back). It is not possible to enqueue then dequeue the same message within the same transaction.
The message is not queued in transaction mode if either the caller is not in transaction mode, or the TPNOTRAN flag is set. Once tpenqueue() returns successfully, the submitted message is guaranteed to be in the queue. When not in transaction mode, if a communication error or a timeout occurs, the application will not know whether or not the message was successfully stored on the queue.
The order in which messages are placed on the queue is controlled by the application via ctl object as described in the EnqueueRequest manual page; the default queue ordering is set when the queue is created.
Additional information about queuing the message can be specified via ctl object. This information includes values to override the default queue ordering placing the message at the top of the queue or before an enqueued message; an absolute or relative time after which a queued message is made available; an absolute or relative time when a message expires and is removed from the queue; the quality of service for delivering the message; the quality of service that any replies to the message should use; a correlation identifier that aids in correlating a reply or failure message with the queued message; the name of a queue to which a reply should be enqueued; and the name of a queue to which any failure message should be enqueued. See the EnqueueRequest object for more information.
qspace
- The name of the queue space to enqueue this message onqname
- The name of the queue within qspace to enqueue this message onctl
- The EnqueueRequest object describing this enqueue operationdata
- The data to be enqueuedflags
- The following is a list of valid flags:When TPNOBLOCK is not set and a blocking condition exists, the caller blocks until the condition subsides or a timeout occurs (either transaction or blocking timeout). If a timeout occurs, the call fails and tperrno in TPException is set to TPETIME.
TPException
- Upon failure, tpenqueue() sets tperrno in TPException
to one of the following values (unless otherwise noted, failure does not
affect the callers transaction, if one exists)
DequeueReply tpdequeue(java.lang.String qspace, java.lang.String qname, byte[] msgid, byte[] corrid, boolean doWait, boolean doPeek, int flags) throws TPException
By default, the message at the top of the queue is dequeued. The order of messages on the queue is defined when the queue is created. The application can request a particular message for dequeuing by specifying its message identifier or correlation identifier. There are also parameters used to indicate that the application wants to wait for a message, in the case when a message is not currently available. It is possible to use tpdequeue to look at a message without removing it from the queue or changing its relative position on the queue.
The message is dequeued in transaction mode if the caller is in transaction mode and the TPNOTRAN flag is not set. This has the effect that if tpdequeue() returns successfully and the caller's transaction is committed successfully, then the message is removed from the queue. If the caller's transaction is rolled back either explicitly or as the result of a transaction timeout or some communication error, then the message will be left on the queue (that is, the removal of the message from the queue is also rolled back). It is not possible to enqueue and dequeue the same message within the same transaction.
The message is not dequeued in transaction mode if either the caller is not in transaction mode, or the TPNOTRAN flag is set. When not in transaction mode, if a communication error or a timeout occurs, the application will not know whether or not the message was successfully dequeued and the message may be lost.
qspace
- The name of the queue space to enqueue this message onqname
- The name of the queue within qspace to enqueue this message onmsgid
- If non-null it requests that the message with this
identifier be dequeued. Note that a message identifier changes if
the message has moved from one queue to anothercorrid
- If non-null it requests that the message with this
correlation id be dequeued. The correlation identifier is specified
by the application when enqueuing the message with tpenqueuedoWait
- If true it indicates that an error should not be returned if
the queue is empty. Instead the process should wait until a message
is available. If doWait is true and msgid or corrid is not null,
it indicates that an error should not be returned if no message with
the specified message identifier or correlation identifier is present
in the queue. Instead, the process should wait until until a message
meeting the criteria is available. The process is still subject to
the caller's transaction timeout, or, when not in transaction mode,
the process is subject to the timeout specified on the TMQUEUE
process by the -t option.doPeek
- If this is true, then the specified message is read but
not removed from the queue. This flag implies the TPNOTRAN flag has
been set for the tpdequeue operation. That is, non-destructive
dequeueing is non-transactional. Note that it is not possible to
read messages enqueued or dequeued within a transaction before the
transaction completes.flags
- The following is a list of valid flags:TPException
- tperrno is set to
one of the following values. (Unless otherwise noted, failure does not
affect the caller's transaction, if one exists.)
DequeueReply tpdequeue(java.lang.String qspace, java.lang.String qname, int flags) throws TPException
msgid
and corrid
set to null.
doWait
and doPeek
set to false.
TPException
void tpterm() throws TPException
tpterm
has been called.
TPException
- if called in the wrong contextConversation tpconnect(java.lang.String svc, TypedBuffer data, int flags) throws TPException
svc
. The name must be one of the conversational service
names posted by a conversational server.
As part of setting up the connection, the caller can pass application data
to the listening program. If the caller chooses to pass data, then
data must be a TypedBuffer. The type and subtype of data must match one
of the types and sub-types recognized by svc
. data
is passed to the
conversational service via the TPServiceInformation structure with which
the service is invoked. The service does not have to call tprecv
to get
the data.
svc
- The conversational service to invokedata
- The initial data to send to the serviceflags
- The following is the list of valid flags svc
is invoked, it is not performed on behalf of the
caller's transaction. Note that code>svc may still be invoked in
transaction mode but it will not be the same transaction: a code>svc may
have as a configuration attribute that it is automatically invoked in
transaction mode. A caller in transaction mode that sets this flag is
still subject to the transaction timeout and no other time out. If a service
fails that was invoked with this flag, the caller's transaction
is not affected.
tpconnect
, the function may block waiting for the reply. When
TPNOBLOCK is not specified and a blocking condition exists, the
caller blocks until the condition subsides or a timeout occurs
(either transaction or blocking timeout).
tpconnect
returns an object that
can be used to send and receive data on this conversation.
TPException
- Upon failure, ttpconnect
returns a TPException exception
to indicate the error condition. tperrno in TPException will be set to one
of the following values:svc
is null
or flags are invalid.
tpacall
with TPNOTRAN,
TPNOBLOCK, and TPNOREPLY set.
tpconnect
was called improperly.
void tpsprio(int prio, int flags) throws TPException
tpenqueue
or tpdequeue
. By default,
the setting of prio
increments or decrements a service's
default priority up to a maximum of 100 or down to a minimum of 1,
depending on its sign, where 100 is the highest priority. The default
priority for a request is determined by the service to which the request
is being sent. This default may be specified administratively
(see UBBCONFIG(5)), or take the system default of 50. tpsprio() has no
effect on messages sent via tpconnect or tpsend
.
A lower priority message does not remain enqueued forever because every
tenth message is retrieved on a "first in, first out" (FIFO) basis.
Response time should not be a concern of the lower priority interface or
service.
flags
may be set to 0 or may be set to TPABSOLUTE.
If TPABSOLUTE is set, then the priority of the next request should be
sent out at the absolute value of prio. The absolute value of prio must
be within the range 1 and 100, inclusive, with 100 being the highest
priority. Any value outside of this range causes a default value to be
used.
- Throws:
TPException
|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |