Package sos.db

Provides transparent persistence to an in-memory or file-based object-oriented database.

See:
Description

Interface Summary

Database	A database of objects.
Progress	A mechanism to allow an operation to report its progress and to check if it should be aborted.
TransactionPolicy	A policy that determines the behavior of database transactions.
TransactionSupport	An auxiliary class that allows a TransactionPolicy to register commit and abort actions and to signal that an object's state has changed.
Unique	A marker interface that indicates that a class does not implement a custom equals or hashCode.

Class Summary

AbstractDatabase	A partial implementation of a database.
AbstractSerializationDatabase	A partial implementation of a serialization-based database.
AbstractTransactionPolicy	A partial implementation of TransactionPolicy.
DefaultReadWriteTransactionPolicy	A transaction policy that uses strict two phase locking (2PL) to ensure that transactions appear to execute sequentially and that uses lock timeouts to break potential deadlock.
DefaultTransactionPolicy	A transaction policy that uses a single database lock to ensure that transactions appear to execute sequentially.
FileDatabase	A persistent database that stores objects in a random-access file.
InMemoryDatabase	A non-persistent database that stores objects in memory.
LongMap<V>	A utility class that maps long keys to Object values.
LongMap.Entry<V>	A utility class used by LongMap that captures a mapping between a long key and an Object value.
ReadOnlyManager	A class that keeps track of whether or not a method is read-only.

Exception Summary

DatabaseCorruptedException	A checked exception indicating that a database is corrupted and cannot be repaired.
DatabaseException	A parent exception to a variety of database exceptions.
NoTransactionException	An unchecked exception indicating that the programmer is performing a transactional operation when no transaction exists.
TransactionAbortedException	A run-time exception (intended to be checked) that indicates a transaction has unexpectedly aborted and rolled back.
TransactionConflictException	A checked exception indicating that a transaction cannot successfully complete because an operation conflicts with that of another transaction.

Package sos.db Description

Provides transparent persistence to an in-memory or file-based object-oriented database. With this package, application developers get:

• An object-oriented database with a simple interface. Just fifteen methods control the creating of the database, the adding and updating of database objects, and the starting and stopping of transactions. The databases are not SQL-based, so there are no tables, schemas, or object-relational mappings. Furthermore, querying is built into the application, providing maximum flexibility.
  
  
• Mostly transparent persistence. An application can use this library without disrupting the business logic or influencing the class hierarchy. Once an object is registered with the database, the object is serialized automatically and updates to the object are reflected in the database automatically. The client application must only specify transaction boundaries and handle the case when a transaction aborts.
  
  
• Transactions and nested transactions. A database transaction, which allows a group of operations to act as a single operation, will exhibit the ACID properties: Atomicity, Consistency, Isolation, and Durability. Client applications can nest transactions arbitrarily deep to achieve maximum code reuse.
  
  
• Fault tolerance. The database can survive an unexpected application or system error.
  
  
• Read-write concurrency. Transactions are allowed to read database objects concurrently, yielding a substantial improvement in throughput if the number of reader transactions exceeds the number of writer transactions.
  
  
• Deadlock detection and avoidance. If concurrent transactions access the same objects, the chance for inconsistent data and deadlock is high. The database ensures data consistency and detects deadlock-prone situations.
  
  
• Versioning. The database can support multiple versions of objects, as long as the evolution abides by Java's rules of binary compatibility.
  
  
• Database logging. Database operations are logged at various levels of granularity. Developers can use the log files to monitor client behavior or to pinpoint application errors.

For more information, see the Database interface and the Persistence Tutorial.