| Home >> All |
| • | tyrex.corba.* (6) | • | tyrex.naming.* (15) | • | tyrex.resource.* (57) | • | tyrex.security.* (15) |
| • | tyrex.services.* (7) | • | tyrex.tm.* (52) | • | tyrex.util.* (28) |
• tyrex: Javadoc index of package tyrex.
Package Samples:
• tyrex.security.container.helper: Principal and credentials used by a J2EE container.
• tyrex.naming.java: JNDI Environment & Service Naming Contexts
• tyrex.tm.xid: Transaction Manager
• tyrex.resource.jdbc: Resource API
• tyrex.corba
• tyrex.naming
• tyrex.resource.castor
• tyrex.resource.javamail
• tyrex.resource.jca.dd
• tyrex.resource.jca
• tyrex.resource.jdbc.xa
• tyrex.resource
• tyrex.security.cert
• tyrex.security.container
• tyrex.security.ldap
• tyrex.security
• tyrex.services
• tyrex.tm.impl
• tyrex.tm
• tyrex.util
Classes:
• UUID: Universally Unique Identifier (UUID) generator. A UUID is an identifier that is unique across both space and time, with respect to the space of all UUIDs. A UUID can be used for objects with an extremely short lifetime, and to reliably identifying very persistent objects across a network. UUIDs are 128 bit values and encoded as 36 character identifiers. This generator produces time-based UUIDs based on the varient specified in a February 4, 1998 IETF draft. Unprefixed identifiers are generated by calling create 55 . A method is also provided to create prefixed identifiers. Prefixed identifiers ...
• FastThreadLocal: This is an efficient implementation of java.lang.ThreadLocal which uses a background thread to remove stale thread entries, doing away with the inefficiencies of java.util.WeakHashMap . This implementation does not support ThreadLocal.initialValue() > ThreadLocal.initialValue() 55 . The default ThreadLocal implementation in Sun's JDK 1.2 is implemented very efficiently, if you count lines of code. But blunt reuse of WeakHashMap doesn't lead to overly efficient use of CPU power. One problem with ThreadLocal, which we're all aware of, is synchronization that through use of a generic adaptor applies ...
• RuntimeContext: The runtime context provides an association between a component or client, the current thread, and resources used by the application. The runtime context keeps track of active transaction, JNDI ENC, security subject, and open connections. It is associated with a component or client, and can be preserved across method invocations by associating it with the current thread. Each thread is associated with a runtime context, whether explicitly or implicitly. A thread can be associated with a particular runtime context by calling setRuntimeContext 55 . If this method was not called, a default runtime ...
• Heuristic: Defines values for different heuristic decisions. During prepare, commit and rollback the transaction manager will reach certain heuristic decisions regarding the transaction and its resources. If the transaction involves no resources, the heuristic decision will be that the transaction is read-only and does not need commit or rollback. If the transaction has been marked for roll back, the heuristic decision will be to roll back the transaction. Otherwise, if the transaction is being commited the heuristic decision is to commit the transaction. During prepare/commit/rollback, certain resources ...
• EnabledDataSource: Implements a JDBC 2.0 javax.sql.DataSource for any arbitrary JDBC driver with JNDI persistance support. XA and pooled connection support is also available, but the application must used the designated DataSource interface to obtain them. The driver class name setDriverClassName(java.lang.String) 55 specifies the class of the JDBC driver to be loaded. The JDBC URL is specified by setDriverName(java.lang.String) 55 . The JDBC URL is of the form jdbc:subprotocol:subname. The initial "jdbc:" is optional so that subprocol:subname is also valid. The supported data source properties are: driverName (required) ...
• WeakList: List of weak references allows objects to be tracked and claimed by the garbage collector. This is a simple implementation based on an array and users java.lang.ref.WeakReference for its entries. The base assumption about this list is that it holds objects used by the application that require extra processing. When the application releases object, we are no longer interested in processing it. This list has preference to not hold or return objects that have been garbage collected (even if not finalized yet). There is no direct access to the list, the only way to retrieve entries is through list() ...
• X509CertificateLoginModule: Implements an X509 certificate validation login module. This module will read the client certificates associated with the subject and determine whether at least one of them was issued by a trusted party. These certificates will further be validated and against a CRL list. The principal of all the validated certificates are added to the subject. A login exception is reported only if the client certificate failed validation (indicates a forged certificate), has expired, or has been listed as revoked in the CRL. This module should be used in one of two modes: Optional - if a trusted certificate is ...
• Journal: Abstract class for transactional journal. This class supports journaling of two-phase commit transactions, recording both prepare, commit, rollback and conslution of transactions. A complete transaction is one for which XAResource.forget has been called. The transaction manager is not interested in recovering complete transactions. During journaling this is indicated by the forget 55 method which closes the transaction chain. During recovery this is indicated by the complete flag and the completed method. During recovery, the outcome of every recovered transaction must be recorded in the journal ...
• Resources: Represents a collection of installed resources. Resources are obtained from this collection by the name with which they were installed. The method addConfiguration 55 is called to install a new resource configuration. The method setTransactionDomain 55 is called to set the transaction domain. The transaction domain is required to create a Resource object from a ResourceConfig object. The deployment process uses the methods addConfiguration 55 and listConfigurations 55 to add and list resource configurations. The application server uses the methods listResources() 55 and getResource 55 to obtain ...
• TwoPhaseConnection: Defines two-phase commit support for a JDBC connection used by XAConnectionImpl . A JDBC connection that can implement any of these features should extend this interface and attempt to implement as much as it can. prepare() 55 is used as part of the two phase commit protocol to determine whether the transaction can commit or must rollback. Failure to implement this method will cause all connections to vote for commit, whether or not they can actually commit, leading to mixed heuristics. enableSQLTransactions(boolean) 55 allows the SQL begin/commit/rollback commands to be disabled for the duration ...
• TransactionDomain: A transaction domain provides centralized management for transactions. A transaction domain defines the policy for all transactions created from that domain, such as default timeout, maximum number of open transactions, IIOP support, and journaling. In addition, the domain maintains resource managers such as JDBC data sources and JCA connectors. The application server obtains a transaction manager or user transaction object, and managed resources from the transaction domain. Transaction domains are created from a domain configuration file. For more information about domain configuration files, ...
• XAConnectionImpl: Implements an X/A connection that can be pooled and managed from inside a transaction monitor. This is the XA connection returned to the application server from the XADataSourceImpl and will be used to obtain ClientConnection for the application. If the transaction is managed through the JDBC interface, this connection will reference the underlying JDBC connection directly. If this resource is enlisted with a global transaction through the javax.transaction.xa.XAResource interface, it will reference a transactional connection, or TxConnection . Such a connection may be shared by two or more XA ...
• PoolLimits: Represents limits placed on a connection pool. The limits are read from the configuration file and apply to the connection pool. The following XML elements are used to specify the pool limits: maximum The maximum number of connections supported, zero if no limit is placed on the connection pool. minimum The minimum number of connections that are always available in the pool. initial The initial connection pool size. maxRetain The maximum time to retain an unused connection, specified in seconds, zero if connections are retained forever. timeout The timeout when attempting to open a new connection, ...
• NestedException: Base type for all Type exceptions. This exception can optionally wrap another exception. The printed stack trace will be that of the wrapped exception, if one is provided in the constructor. The underlying exception can be obtained from getException 55 . Several exceptions support wrapping of an underlying exception by extending from this class. When another nested exception is provided in the constructor, the underlying exception will be used, so it's safe to construct a nested exception from another nested exception. Support for unwrapping the underlying exceptions include NestedException , org.xml.sax.SAXException ...
• DaemonMaster: The daemon master is responsible for starting, terminating and restarting daemon thread. A daemon thread is a thread that is kept live for the duration of the server's life and is only terminated when the server is stopped. A sudden termination of a daemon thread is an unwelcome occurance in the life time of the system. The daemon master protects the system from the sudden and unexpected termination of daemons by automatically restarting them. A daemon implements the Runnable interface which allows it to be executed on any given thread. The daemon master assigns a thread within the daemon master's ...
• ConnectorLoader: Provides a means to create managed connections and connection factories from a connector loaded in a separate class loader. In order to enable deployment of multiple connector versions and their dependent JARs, each connector can be loaded in a separate class loader. The connector deployment descriptor specifies the interface and implementation classes used by the connector. This class provides a mechanism to obtain a new managed connection and a new connection factory from a connector loaded in a separate class loader. In addition, it validates that connection and factory objects match the classes ...
• TransactionImpl: Implements a global transaction. This transaction supports X/A resources (see javax.transaction.xa.XAResource ), can be part of an OTS global transaction (see ResourceImpl ) and can contain OTS subtransactions (see Resource ). Tightly integrated with TransactionManagerImpl and TransactionServer . Synchronizations are called in the reverse order in which they are added.
• ControlImpl: Implements a Control interface into a transaction. Transactions are implemented strictly by TransactionImpl , however when using the OTS API or communicating with other CORBA servers it is necessary to use the control interface. This object serves as lightweight adapter between the transaction and control interface. Control objects are produced directly only by TransactionImpl and indirectly by TransactionFactory .
• XAResourceCallback: This interface defines methods that inform when the XA resource associated with this callback has been enlisted in a transaction, i.e. javax.transaction.XA.XAResource.start(javax.transaction.XA.XAResource.TMSTART) has been called, delisted from the transaction, i.e. javax.transaction.XA.XAResource.end(javax.transaction.XA.XAResource.TMSUCCESS or javax.transaction.XA.XAResource.TMFAIL) has been called, committed/rolled back, i.e.javax.transaction.XA.XAResource.commit() or javax.transaction.XA.XAResource.rollback(). It is assumed that a XAResourceCallback is associated with only one XA Resource.
• UserTransactionImpl: Simple implementation of the javax.transaction.UserTransaction interface. This is a local implementation exposed to local users through JNDI lookup or through the application server. This interface is decoupled from TransactionManagerImpl to prevent unwanted casting, since the later is public. To obtain the user transaction use either Tyrex or look it up through JNDI ( java:/comp/UserTransaction ).
• TransactionInterceptor: The interceptor interface allows an external engine to hook up into the transaction monitor and either record the outcome of transactions or affect them. The interceptor is notified when transactions are created, attempt to commit, rolled back, and when they are resumed or suspended from threads. The interceptor may affect the outcome of an attempt to commit or resume a transaction. The interceptor is notified of the outcome of each transaction in the form of a heuristic decision made regarding the transaction and all it's resources.
• TyrexDatabaseMetaDataImpl: This is a implementation of java.sql.DatabaseMetaData that returns Tyrex implementations of java.sql.Connection ( getConnection() 55 ) and java.sql.ResultSet (various get methods). This is done so that the actual connections can never be accessed directly so that they can be pooled ( tyrex.jdbc.ServerDataSource and tyrex.jdbc.xa.XADataSourceImpl ). This class is thread safe.
• Clock: Provides an efficient mechanism for obtaining the current system time. Uses a background thread to automatically increment an internal clock and periodically synchronize with the system clock. The method clock 55 is more efficient than currentTimeMillis 55 , and also allows the clock to be artificially advanced for testing purposes. The clock is thread-safe and consumes a single thread.
• SecureConnection: Credentials indicating a secure connection. This credentials inform the container that it has established a secure connection with the client. It does not tell the container anything about the client (e.g. whether the certificate is trusted), only that the server has used it's secure connection capabilities. The definition of what a secure connection is depends on the container configuration, e.g. some containers may regard 48-bit SSL as secure, others may require 128-bit and an IPSEC connection, etc.
| Home | Contact Us | Privacy Policy | Terms of Service |