| Home >> All >> ojb >> [ odmg Javadoc ] |
| • | ojb.odmg.collections.* (9) | • | ojb.odmg.locking.* (17) | • | ojb.odmg.lockstrategy.* (6) |
| • | ojb.odmg.oql.* (4) | • | ojb.odmg.states.* (7) |
• ojb.odmg: Javadoc index of package ojb.odmg.
Package Samples:
• ojb.odmg.lockstrategy
• ojb.odmg.states
• ojb.odmg.collections
• ojb.odmg.oql
• ojb.odmg.locking
Classes:
• LockManagerDefaultImpl: The OJB default implementation of a Locking mechanism. This Implementation supports 4 transaction isolation levels as specified in the interface ojb.broker.metadata.IsolationLevels: public final int IL_READ_UNCOMMITTED = 0; public final int IL_READ_COMMITTED = 1; public final int IL_REPEATABLE_READ = 2; public final int IL_SERIALIZABLE = 3; Isolationlevels can be adjusted per class. The proper lockhandling is done in the respective LockStrategy implementation. This default implementation provides persistent Locks that are stored in a special database table. To keep the locks in the database and ...
• TransactionAware: TransactionAware is an interface that can be implemented to provide hooks into the Transaction interface provided by ObJectRelationalBridge. Only objects which have a write lock acquired on them can participate in a transaction. To kill a transaction, implement beforeCommit() and throw a TransactionAbortedException. This will force the entire transaction to rollback. To rebuild an object after a rollback use the afterAbort() call. This is a good place to populate transient or other variables. beforeAbort and afterCommit are there for informational purposes. Here are some common ways you can expect ...
• LockManager: This interface declares the functionality of the OJB internal Locking mechanism. A default implementaion LockManagerDefaultImpl is provided. This implementaion keeps distributed locks in the database. The locking mechanisms thus involves a lot of database lookups and writes. For some environments this solution may not be adequate. OJB allows to provide user defined implementations of this interface. To activate a user defined LockManagerDefaultImpl it must be configured in the OJB.properties file.
• ReadUncommittedStrategy: The implementation of the Uncommited Reads Locking strategy. This strategy is the loosest of them all. It says you shouldn't need to get any Read locks whatsoever, but since it will probably try to get them, it will always give it to them. Locks are obtained on modifications to the database and held until end of transaction (EOT). Reading from the database does not involve any locking. Allows: Dirty Reads Non-Repeatable Reads Phantom Reads
• TransactionTable: TransactionTable provides a mapping between the calling thread and the Transaction it is currently using. One thread can be joined with one transaction at a certain point in time. But a thread can join with different transactions subsequently. This mapping from threads to Transactions is based on ODMG.
• ReadCommittedStrategy: The implementation of the Commited Reads Locking stra ReadCommitted - Reads and Writes require locks. Locks are acquired for reading and modifying the database. Locks are released after reading but locks on modified objects are held until EOT. Allows: Non-Repeatable Reads Phantom Readstegy.
• OJBJ2EE: in the non J2EE OJB implementation we maintain a table of transactions ourselves in this version, we get the Transaction from the Monitor and do the association ourselves. It ends up being essentially the same, except the currentThread is replaced by the Trans monitor as the discriminator.
• RepeatableReadStrategy: The implementation of the Repeatable Reads Locking strategy. Locks are obtained for reading and modifying the database. Locks on all modified objects are held until EOT. Locks obtained for reading data are held until EOT. Allows: Phantom Reads
• NamedRootsMap: ODMG NamedRoots implementation. this implementation stores the (name, Identity) pairs in a database table. therefore the NamedRootsMap underlies the same transaction management as all other persistent objects
• LockEntry: a persistent entry for locks. All locks that are hold from transaction on objects are represented by a LockENtry and made persistent to the database.
• StateOldClean: this state represents old Objects (i.e. already persistent but not changed during tx) --> no need to do anything for commit or rollback
• LockStrategy: this interface defines method that a Locking Strategy must implement according to the transaction isolation level it represents. *
• AbstractLockStrategy: The base class of all LockingStrategies. It provides the basic infrastructure to read and write locks to the persistent storage.
• NamedRootsEntry: represents an entry to the named roots table. maps names (Strings) to OJB Identities Creation date: (26.01.2001 19:57:51)
• ObjectEnvelopeTable: manages all ObjectEnvelopes included by a transaction. Performs commit, and rollack operations on all included Envelopes.
• OJB: Facade to the persistence ObjectServer system. Implements the factory interface for a particular ODMG implementation.
• RWLockFactory: Title: ObJectBridge Description: Object Relational Mapping tool Copyright: Copyright (c) 2000 Company:
• LockManagerFactory: This factory class creates LockManager instances according to the setting in the OJB properties file.
• ObjectEnvelope: ObjectEnvelope is used during ODMG transactions as a wrapper for a persistent objects declaration
• StateOldDelete: this state represents old objects which have been marked for deletion during tx.
• StateNewDelete: this state represents new objects which have been mrked for deletion during tx.
• ModificationState: Describes an objects transactional state regarding commiting and rollbacking
• DSetEntry: Insert the type's description here. Creation date: (26.02.2001 13:18:35)
• DListIterator: Insert the type's description here. Creation date: (09.02.2001 15:49:39)
• DBagImpl: Insert the type's description here. Creation date: (25.02.2001 12:53:12)
| Home | Contact Us | Privacy Policy | Terms of Service |