weblogic.wtc.jatmi
Interface ApplicationToMonitorInterface
- All Known Implementing Classes:
- TuxedoConnection
- public interface ApplicationToMonitorInterface
This interface represents atmi in java, or jatmi.
- Author:
- BEA Systems, Inc.
Copyright © 2001 BEA Systems, Inc. All Rights Reserved.
Field Summary
|
static int |
TPABSOLUTE
Internal flag |
static int |
TPACK
Request acknowledgment of tpnotify |
static int |
TPAPPAUTH
system and application authentication |
static int |
TPCONV
For internal use only |
static int |
TPGETANY
Get any reply |
static int |
TPNOAUTH
no authentication necessary |
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
used to flag outbound RMI/IIOP calls |
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 necessary |
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)
routine for sending a service request. |
Reply |
tpcall(java.lang.String svc,
TypedBuffer data,
int flags)
tpcall() sends a request and synchronously awaits its reply. |
Conversation |
tpconnect(java.lang.String svc,
TypedBuffer data,
int flags)
Allows a program to set up 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)
tpdequeue() takes 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)
This method is the same as calling the other tpdequeue method with
null for msgid and corrid and false for doWait and doPeek |
byte[] |
tpenqueue(java.lang.String qspace,
java.lang.String qname,
EnqueueRequest ctl,
TypedBuffer data,
int flags)
tpenqueue() stores a message on the queue named by qname in the qspace
queue space. |
Reply |
tpgetrply(CallDescriptor cd,
int flags)
tpgetrply() returns a reply from a previously sent request. |
void |
tpterm()
tpterm is how this object dissasociates itself from the Tuxedo
session. |
TPNOBLOCK
public static final int TPNOBLOCK
- Do not block
TPSIGRSTRT
public static final int TPSIGRSTRT
- Restart on signal (not used in jatmi)
TPNOREPLY
public static final int TPNOREPLY
- No reply expected
TPNOTRAN
public static final int TPNOTRAN
- Do not execute inside current transaction
TPTRAN
public static final int TPTRAN
- Execute in a trasaction
TPNOTIME
public static final int TPNOTIME
- Do not time out this call
TPABSOLUTE
public static final int TPABSOLUTE
- Internal flag
TPGETANY
public static final int TPGETANY
- Get any reply
TPNOCHANGE
public static final int TPNOCHANGE
- Do not allow buffer type to change (not used in jatmi)
TPCONV
public static final int TPCONV
- For internal use only
TPSENDONLY
public static final int TPSENDONLY
- Set conversation to send only mode
TPRECVONLY
public static final int TPRECVONLY
- Set conversation to read only mode
TPACK
public static final int TPACK
- Request acknowledgment of tpnotify
TPRMICALL
public static final int TPRMICALL
- used to flag outbound RMI/IIOP calls
TPUNKAUTH
public static final int TPUNKAUTH
- unknown authentication level
TPNOAUTH
public static final int TPNOAUTH
- no authentication necessary
TPSYSAUTH
public static final int TPSYSAUTH
- system password authentication necessary
TPAPPAUTH
public static final int TPAPPAUTH
- system and application authentication
tpacall
public CallDescriptor tpacall(java.lang.String svc,
TypedBuffer data,
int flags)
throws TPException
- routine for sending a service request.
tpacall sends a request message 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(). 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. The type and
sub-type of data must match one of the types and sub-types recognized
by svc. Note that for each request sent while in transaction mode, a
corresponding reply must ultimately be received.
- Parameters:
svc
- The service name to calldata
- The data to send to the serviceflags
-
- TPNOTRAN If the caller is in transaction mode and this flag is set,
then when svc is invoked, it is not performed on behalf of the
caller's transaction. If svc belongs to a server that does not
support transactions, then 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 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). If a
service fails that was invoked with this flag, the caller's
transaction is not affected.
- TPNOREPLY Informs tpacall() that a reply is not expected. When
TPNOREPLY is set, the function returns 0 on success, where 0 is an
invalid descriptor. When the caller is in transaction mode, this
setting cannot be used unless TPNOTRAN is also set.
- TPNOBLOCK The request is not sent if a blocking condition exists
(for example, the internal buffers into which the message is
transferred are full). 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).
- TPNOTIME This flag signifies that the caller is willing to block
indefinitely and wants to be immune to blocking timeouts. Transaction
timeouts may still occur.
- Returns:
- Upon successful completion, tpacall() returns a CallDescriptor
that can be used to receive the reply of the request sent.
- Throws:
- TPException - Upon failure, tpacall() returns a TPException exception
to indicate the error condition. tperrno in TPException will be set to one
of the following values:
- TPEINVAL Invalid arguments were given (for example, svc is null,
or flags are invalid).
- TPENOENT Cannot send to svc because it does not exist or is a
conversational service.
- TPEITYPE The type and sub-type of data is not one of the allowed
types and sub-types that svc accepts.
- TPELIMIT The caller's request was not sent because the maximum
number of outstanding asynchronous requests has been reached.
- TPETRAN svc belongs to a server that does not support transactions
and TPNOTRAN was not set.
- TPETIME A timeout occurred. If the caller is in transaction mode,
then a transaction timeout occurred and the transaction is marked
abort-only; otherwise, a blocking timeout occurred and neither
TPNOBLOCK nor TPNOTIME was specified. If a transaction timeout
occurred, then with one exception, any attempts to send new requests
or receive outstanding replies will fail with TPETIME until the
transaction has been aborted. The exception is a request that does
not block, expects no reply, and is not sent on behalf of the
caller's transaction (that is, tpacall() with TPNOTRAN,
TPNOBLOCK, and TPNOREPLY set).
- TPEBLOCK A blocking condition exists and TPNOBLOCK was specified.
- TPEPROTO tpacall() was called improperly.
- TPESYSTEM A BEA Tuxedo system error has occurred. The exact nature of
the error is written to a log file.
- TPEOS An operating system error has occurred. If a message queue on a
remote location is filled, TPEOS may be returned even if
tpacall() returned successfully.
tpgetrply
public Reply tpgetrply(CallDescriptor cd,
int flags)
throws TPException,
TPReplyException
- tpgetrply() returns a reply from a previously sent request. This
function's first argument, cd, is a call descriptor returned by
tpacall(). By default, the function waits until the reply matching
cd arrives or a timeout occurs.
Within any particular context of a multithreaded program:
- Calls to tpgetrply(TPGETANY) and tpgetrply() for a specific
handle cannot be issued concurrently.
- Multiple calls to tpgetrply(TPGETANY) cannot be issued concurrently.
- Any tpgetrply() call that would, if issued, cause a violation of
either of these restrictions, throws a TPException with errno set to
TPEPROTO.
It is acceptable to issue:
- Concurrent calls to tpgetrply() for different handles
- A call to tpgetrply(TPGETANY) in a single context concurrently
with a call to tpgetrply(), with or without TPGETANY, in a different
context
- Parameters:
cd
- The CallDescriptor previously returned from tpacall, or null
if TPGETANY is set in flagsflags
- The following is a list of valid flags:
- TPGETANY This flag signifies that tpgetrply() should ignore the
call descriptor cd, return any reply available and set cd
in the replyrtn object corresponding to the reply returned.
If no replies exist, tpgetrply() by default will wait for one to
arrive.
- TPNOBLOCK tpgetrply() does not wait for the reply to arrive. If the
reply is available, then tpgetrply() gets the reply and returns.
When this flag is not specified and a reply is not available, the
caller blocks until the reply arrives or a timeout occurs (either
transaction or blocking timeout).
- TPNOTIME This flag signifies that the caller is willing to block
indefinitely for its reply and wants to be immune to blocking
timeouts. Transaction timeouts may still occur.
- Returns:
- Upon success of tpgetrply() a Reply object that contains the
reply data from the service, the service return status and the call
descriptor of the returned data. Note that the service may not have
returned succesfully, and that the reply status in the returned object
should always be checked for failures.
- Throws:
- TPException - Upon failure, tpgetrply() throws TPException() to indicate the
error condition. tperrno in TPException will be set to one of the following
values:
- TPEINVAL Invalid arguments were given (for example, cd or flags are
invalid).
- TPEOTYPE The type and sub-type of the reply are not known to the
caller. If the reply was to be received on behalf of the caller's
current transaction, then the transaction is marked abort-only
since the reply is discarded.
- TPEBADDESC cd points to an invalid descriptor.
- TPETIME A timeout occurred. If the caller is in transaction mode,
then a transaction timeout occurred and the transaction is marked
abort-only; otherwise, a blocking timeout occurred and neither
TPNOBLOCK nor TPNOTIME were specified. If a transaction timeout
occurred, then with one exception, any attempts to send new requests
or receive outstanding replies will fail with TPETIME until the
transaction has been aborted. The exception is a request that does
not block, expects no reply and is not sent on behalf of the
caller's transaction (that is, tpacall() with TPNOTRAN,
TPNOBLOCK and TPNOREPLY set).
- TPEBLOCK A blocking condition exists and TPNOBLOCK was specified.
- TPEPROTO tpgetrply() was called improperly.
- TPESYSTEM A BEA Tuxedo system error has occurred. The exact nature
of the error is written to a log file.
- TPEOS An operating system error has occurred. If a message queue on
a remote location is filled, TPEOS may possibly be returned.
- TPReplyException - If there was a service failure (TPESVCFAIL or
TPSVCERROR) in which case the exception will also have the 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 shall have been thrown on behalf of a certain outstanding
request, and that request will be considered to have completed
with a failure.
tpcall
public Reply tpcall(java.lang.String svc,
TypedBuffer data,
int flags)
throws TPException,
TPReplyException
- tpcall() sends a request and synchronously awaits its reply. A call to
this function is the same as calling 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 data portion of a request is pointed
to by data, an object implementing TypedBuffer. Also, data may be null.
The type and sub-type of data must match one of the types and sub-types
recognized by svc.
- Parameters:
svc
- The service name to calldata
- The data to send to the serviceflags
- The following is a list of valid flags:
- TPNOTRAN If the caller is in transaction mode and this flag is set,
then when svc is invoked, it is not performed on behalf of the
caller's transaction. Note that svc may still be invoked in
transaction mode but it will not be the same transaction: a 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). If a service
fails that was invoked with this flag, the caller's transaction
is not affected.
- TPNOBLOCK The request is not sent if a blocking condition exists (for
example, the internal buffers into which the message is transferred
are full). Note that this flag applies only to the send portion of
tpcall(): 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).
- TPNOTIME This flag signifies that the caller is willing to block
indefinitely and wants to be immune to blocking timeouts. However,
if the caller is in transaction mode, this flag has no effect; it
is subject to the transaction timeout limit. Transaction timeouts
may still occur.
- Returns:
- Upon success of tpcall() a Reply object that contains the
reply data from the service and the service return status.
Note that the service may not have returned succesfully, and that the
reply status in the returned object should always be checked
for failures.
- Throws:
- 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.)
- TPEINVAL Invalid arguments were given (for example, svc is null or
flags are invalid).
- TPENOENT Cannot send to svc because it does not exist, or it is a
conversational service, or the name provided begins with a dot (.).
- TPEITYPE The type and sub-type of data is not one of the allowed
types and sub-types that svc accepts.
- TPEOTYPE The type and sub-type of the reply are not known to the caller. * If the service request was made on behalf of the caller's current
transaction, then the transaction is marked abort-only since the
reply is discarded.
- TPETRAN svc belongs to a server that does not support transactions
and TPNOTRAN was not set.
- TPETIME A timeout occurred. If the caller is in transaction mode, then
a transaction timeout occurred and the transaction is marked
abort-only; otherwise, a blocking timeout occurred and
neither TPNOBLOCK nor TPNOTIME was specified. If a transaction
timeout occurred, then with one exception, any attempts to send new
requests or receive outstanding replies will fail with TPETIME until
the transaction has been aborted. The exception is a request that
does not block, expects no reply, and is not sent on behalf of the
caller's transaction (that is, tpacall with TPNOTRAN, TPNOBLOCK,
and TPNOREPLY set).
- TPEBLOCK A blocking condition was found on the send call and
TPNOBLOCK was specified.
- TPEPROTO tpcall() was called improperly.
- TPESYSTEM A BEA Tuxedo system error has occurred. The exact nature
of the error is written to a log file.
- TPEOS An operating system error has occurred. If a message queue on a
remote location is filled, TPEOS may be returned even if tpcall()
returned successfully.
- TPReplyException - If there was a service failure (TPESVCFAIL or
TPSVCERROR) in which case the exception will also have the reply
data from the service.
tpenqueue
public byte[] tpenqueue(java.lang.String qspace,
java.lang.String qname,
EnqueueRequest ctl,
TypedBuffer data,
int flags)
throws TPException
- tpenqueue() stores a message on the queue named by qname in the qspace
queue space. A queue space is a collection of queues, one of which must
be qname.
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.
- Parameters:
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:
- TPNOTRAN If the caller is in transaction mode and this flag is set,
the message is not queued within the caller's transaction. A caller
in transaction mode that sets this flag is still subject to the
transaction timeout (and no other) when queuing the message. If
message queuing fails, the caller's transaction is not affected.
- TPNOBLOCK The message is not enqueued if a blocking condition exists.
If this flag is set and a blocking condition exists such as the
internal buffers into which the message is transferred are full, the
call fails and tperrno in TPException is set to TPEBLOCK. If this flag is set
and a blocking condition exists because the target queue is opened
exclusively by another application, the call succeeds but the
diagnostic field of the Enqueue object is set to QMESHARE. In the
latter case, the other application, which is based on a BEA product
other than the BEA Tuxedo system, opened the queue for exclusive
read and/or write using the Queuing Services API (QSAPI).
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.
- TPNOTIME Setting this flag signifies that the caller is willing to
block indefinitely and wants to be immune to blocking timeouts.
Transaction timeouts may still occur.
- Returns:
- The message id of the enqueued message
- Throws:
- 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)
- TPEINVAL Invalid arguments were given (for example, qspace is null
or flags are invalid).
- TPENOENT Cannot access the qspace because it is not available
(that is, the associated TMQUEUE(5) server is not available), or
cannot start a global transaction due to the lack of entries in the
Global Transaction Table (GTT).
- TPETIME A timeout occurred. If the caller is in transaction mode, a
transaction timeout occurred and the transaction is to be aborted;
otherwise, a blocking timeout occurred and neither TPNOBLOCK nor
TPNOTIME was specified. If a transaction timeout occurred, any
attempts to enqueue new messages will fail with TPETIME until the
transaction has been aborted.
- TPEBLOCK A blocking condition exists and TPNOBLOCK was specified.
- TPEPROTO tpenqueue() was called improperly.
- TPESYSTEM A BEA Tuxedo system error has occurred. The exact nature of
the error is written to a log file.
- TPEOS An operating system error has occurred.
- TPEDIAGNOSTIC One of the following values is available in the
diagnostic field of the execption:
- QMEINVAL An invalid flag value was specified.
- QMEBADRMID An invalid resource manager identifier was specified.
- QMENOTOPEN The resource manager is not currently open.
- QMETRAN The call was not in transaction mode or was made with the
TPNOTRAN flag set and an error occurred trying to start a
transaction in which to enqueue the message. This diagnostic is not
returned by queue managers from BEA Tuxedo Release 7.1 or later.
- QMEBADMSGID An invalid message identifier was specified.
- QMESYSTEM A system error occurred. The exact nature of the error is
written to a log file.
- QMEOS An operating system error occurred.
- QMEABORTED The operation was aborted. When executed within a global
transaction, the global transaction has been marked rollback-only.
Otherwise, the queue manager aborted the operation.
- QMEPROTO An enqueue was done when the transaction state was not active.
- QMEBADQUEUE An invalid or deleted queue name was specified.
- QMENOSPACE Due to an insufficient resource, such as no space on the
queue, the message with its required quality of service (persistent
or non-persistent storage) was not enqueued. QMENOSPACE is returned
when any of the following configured resources is exceeded: (1) the
amount of disk (persistent) space allotted to the queue space, (2) the
amount of memory (non-persistent) space allotted to the queue space,
(3) the maximum number of simultaneously active transactions allowed
for the queue space, (4) the maximum number of messages that the queue
space can contain at any one time, (5) the maximum number of
concurrent actions that the Queuing Services component can handle, or
(6) the maximum number of authenticated users that may concurrently
use the Queuing Services component.
- QMERELEASE An attempt was made to enqueue a message to a queue manager
that is from a version of the BEA Tuxedo system that does not support
a newer feature.
- QMESHARE When enqueuing a message from a specified queue, the
specified queue is opened exclusively by another application. The
other application is one based on a BEA product other than the BEA
Tuxedo system that opened the queue for exclusive read and/or write
using the Queuing Services API (QSAPI).
tpdequeue
public DequeueReply tpdequeue(java.lang.String qspace,
java.lang.String qname,
byte[] msgid,
byte[] corrid,
boolean doWait,
boolean doPeek,
int flags)
throws TPException
- tpdequeue() takes a message for processing from the queue named by qname
in the qspace queue space.
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.
- Parameters:
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:
- TPNOTRAN If the caller is in transaction mode and this flag is set,
the message is not dequeued within the caller's transaction. A caller
in transaction mode that sets this flag is still subject to the
transaction timeout (and no other) when dequeuing the message. If
message dequeuing fails, the caller's transaction is not affected.
- TPNOBLOCK The message is not dequeued if a blocking condition exists.
If this flag is set and a blocking condition exists such as the
internal buffers into which the message is transferred are full, the
call fails and TPException() is set to TPEBLOCK. If this flag is set and
a blocking condition exists because the target queue is opened
exclusively by another application, the call will throw an exception,
and the diagnostic value in the TPException object is set to QMESHARE.
In the latter case, the other application, which is based
on a BEA product other than the BEA Tuxedo system, opened the queue
for exclusive read and/or write using the Queuing Services API (QSAPI).
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). This blocking condition does not
include blocking on the queue itself if doWait is true.
- TPNOTIME Setting this flag signifies that the caller is willing to
block indefinitely and wants to be immune to blocking timeouts.
Transaction timeouts may still occur.
- Returns:
- If tpdequeue() returns successfully, the application can retrieve
additional information about the message using the DequeueReply object.
The information may include the message identifier
for the dequeued message; a correlation identifier that should
accompany any reply or failure message so that the originator can
correlate the message with the original request; the quality of
service the message was delivered with, the quality of service any
replies to the message should be delivered with; the name of a reply
queue if a reply is desired; and the name of the failure queue on
which the application can queue information regarding failure to
dequeue the message. These are described in the DequeueReply object
manual page.
- Throws:
- TPException - tperrno is set to
one of the following values. (Unless otherwise noted, failure does not
affect the caller's transaction, if one exists.)
- TPEINVAL Invalid arguments were given (for example, qname is null or
flags are invalid).
- TPENOENT Cannot access the qspace because it is not available (that
is, the associated TMQUEUE(5) server is not available), or cannot
start a global transaction due to the lack of entries in the Global
Transaction Table (GTT).
- TPEOTYPE The type and sub-type of the dequeued message are not known
to the caller. When the call is made in transaction mode and this
error occurs, the transaction is marked abort-only, and the message
remains on the queue.
- TPETIME A timeout occurred. If the caller is in transaction mode, a
transaction timeout occurred and the transaction is to be aborted;
otherwise, a blocking timeout occurred and neither TPNOBLOCK nor
TPNOTIME was specified. If a transaction timeout occurred, any
attempts to dequeue new messages will fail with TPETIME until the
transaction has been aborted.
- TPEBLOCK A blocking condition exists and TPNOBLOCK was specified.
- TPEPROTO tpdequeue() was called improperly. There is no effect on the
queue or the transaction.
- TPESYSTEM A BEA Tuxedo system error has occurred. The exact nature of
the error is written to a log file. There is no effect on the queue.
- TPEOS An operating system error has occurred. There is no effect on
the queue.
- TPEDIAGNOSTIC The following diagnostic values may be returned in the
exception:
- QMEINVAL An invalid flag value was specified.
- QMEBADRMID An invalid resource manager identifier was specified.
- QMENOTOPEN The resource manager is not currently open.
- QMETRAN The call was not in transaction mode or was made with the
TPNOTRAN flag set and an error occurred trying to start a transaction
in which to dequeue the message. This diagnostic is not returned by
queue managers from BEA Tuxedo Release 7.1 or later.
- QMEBADMSGID An invalid message identifier was specified for dequeuing.
- QMESYSTEM A system error has occurred. The exact nature of the error
is written to a log file.
- QMEOS An operating system error has occurred.
- QMEABORTED The operation was aborted. When executed within a global
transaction, the global transaction has been marked rollback-only.
Otherwise, the queue manager aborted the operation.
- QMEPROTO A dequeue was done when the transaction state was not active.
- QMEBADQUEUE An invalid or deleted queue name was specified.
- QMENOMSG No message was available for dequeuing. Note that it is
possible that the message exists on the queue and another application
process has read the message from the queue. In this case, the message
may be put back on the queue if that other process rolls back the
transaction.
- QMEINUSE When dequeuing a message by message identifier or
correlation identifier, the specified message is in use by another
transaction. Otherwise, all messages currently on the queue are in
use by other transactions. This diagnostic is not returned by
queue managers from BEA Tuxedo Release 7.1 or later.
- QMESHARE When dequeuing a message from a specified queue, the
specified queue is opened exclusively by another application. The
other application is one based on a BEA product other than the BEA
Tuxedo system that opened the queue for exclusive read and/or write
using the Queuing Services API (QSAPI).
- QMERELEASE An attempt was made to dequeue a message to a queue manager
that is from a version of the BEA Tuxedo system that does not support
a newer feature.
tpdequeue
public DequeueReply tpdequeue(java.lang.String qspace,
java.lang.String qname,
int flags)
throws TPException
- This method is the same as calling the other tpdequeue method with
null for msgid and corrid and false for doWait and doPeek
tpterm
public void tpterm()
throws TPException
- tpterm is how this object dissasociates itself from the Tuxedo
session. No further ATMI calls can be made on this object after
this method has been called.
- Throws:
- TPException - if called in the wrong context
tpconnect
public Conversation tpconnect(java.lang.String svc,
TypedBuffer data,
int flags)
throws TPException
- Allows a program to set up a half-duplex connection to a conversational
service, 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.
- Parameters:
svc
- The conversational service to invokedata
- The initial data to send to the serviceflags
- The following is the list of valid flags
- TPNOTRAN If the caller is in transaction mode and this flag is set,
then when svc is invoked, it is not performed on behalf of the
caller's transaction. Note that svc may still be invoked in
transaction mode but it will not be the same transaction: a 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). If a service
fails that was invoked with this flag, the caller's transaction
is not affected.
- TPSENDONLY The caller wants the connection to be set up initially
such that it can only send data and the called service can only receive
data (that is, the caller initially has control of the connection). Either
TPSENDONLY or TPRECVONLY must be specified.
- TPRECVONLY The caller wants the connection to be set up initially
such that it can only receive data and the called service can only send
data (that is, the service being called initially has control of the
connection). Either TPSENDONLY or TPRECVONLY must be specified.
- TPNOBLOCK The request is not sent if a blocking condition exists (for
example, the internal buffers into which the message is transferred
are full). Note that this flag applies only to the send portion of
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).
- TPNOTIME This flag signifies that the caller is willing to block
indefinitely and wants to be immune to blocking timeouts. However,
if the caller is in transaction mode, this flag has no effect; it
is subject to the transaction timeout limit. Transaction timeouts
may still occur.
- Returns:
- Upon successful completion, tpconnect returns an object that
can be used to send and receive data on this conversation.
- Throws:
- TPException - Upon failure, tpconnect() returns a TPException exception
to indicate the error condition. tperrno in TPException will be set to one
of the following values:
- TPEINVAL Invalid arguments were given (for example, svc is null,
or flags are invalid).
- TPETIME A timeout occurred. If the caller is in transaction mode,
then a transaction timeout occurred and the transaction is marked
abort-only; otherwise, a blocking timeout occurred and neither
TPNOBLOCK nor TPNOTIME was specified. If a transaction timeout
occurred, then with one exception, any attempts to send new requests
or receive outstanding replies will fail with TPETIME until the
transaction has been aborted. The exception is a request that does
not block, expects no reply, and is not sent on behalf of the
caller's transaction (that is, tpacall() with TPNOTRAN,
TPNOBLOCK, and TPNOREPLY set).
- TPEPROTO tpconnect() was called improperly.
- TPESYSTEM A BEA Tuxedo system error has occurred. The exact nature of
the error is written to a log file.
WebLogic classes and methods that do not appear in this reference are not public and are not supported.