After creating a tmTransaction either through new or as a member or local variable a process must call Init() with the proper set of arguements to initialize the state of the transaction. tmTransaction is set up to accept 3 types of initialization.
1) Raw message - All data is carried in the byte pointer aMessage, args 2,3,4 should be set to TM_NO_ID and aLength must be set to the full length of aMessage, including null termination if the payload is a null-term string and the size of the tmHeader struct preceeding the message. Currently this format is used at the IPC boundary, where we receive a byte pointer from the IPC Daemon.
2) Flags only - aQueueID, aAction and aStatus are all set. aMessage should be set to nsnull and aLength to 0. This format is used when sending reply messages (except for ATTACH_REPLY) and when the TS Transaction Service is sending "control" messages to the Manager - flush, detach, etc...
3) Flags and message - All arguements are set. The aMessage is only the message for the client app. aLength should be set to the length of aMessage and not include the length of the tmHeader struct.
The only data member you can set post initialization is the QueueID. You should only call Init() once in the lifetime of a tmTransaction as it doesn't clean up the exisiting data before assigning the new data. Therefore it would leak most heinously if Init() were to be called twice.
mOwnerID only has relevance on the IPC daemon side of things. The Transaction Service has no knowledge of this ID and makes no use of it.
Public Member Functions
|PRUint32||GetAction () const|
|const PRUint8 *||GetMessage () const|
|PRUint32||GetMessageLength () const|
|PRUint32||GetOwnerID () const|
|PRInt32||GetQueueID () const|
|const PRUint8 *||GetRawMessage () const|
|PRUint32||GetRawMessageLength () const|
|PRInt32||GetStatus () const|
|nsresult||Init (PRUint32 aOwnerID, PRInt32 aQueueID, PRUint32 aAction, PRInt32 aStatus, const PRUint8 *aMessage, PRUint32 aLength)|
|void||SetQueueID (PRInt32 aID)|