Examples of com.sleepycat.je.SecondaryDatabase

• com.sleepycat.je.SecondaryDatabase
  primary database must already be open. SecondaryKeyCreator keyCreator; // Your key creator implementation. SecondaryConfig secConfig = new SecondaryConfig(); secConfig.setAllowCreate(true); secConfig.setSortedDuplicates(true); secConfig.setKeyCreator(keyCreator); SecondaryDatabase newDb = env.openSecondaryDatabase(transaction, "myDatabaseName", primaryDb, secConfig)

  If a primary database is to be associated with one or more secondary databases, it may not be configured for duplicates.

  WARNING: The associations between primary and secondary databases are not stored persistently. Whenever a primary database is opened for write access by the application, the appropriate associated secondary databases should also be opened by the application. This is necessary to ensure data integrity when changes are made to the primary database. If the secondary database is not opened, it will not be updated when the primary is updated, and the references between the databases will become invalid. (Note that this warning does not apply when using the {@link com.sleepycat.persist DPL}, which does store secondary relationships persistently.)

  Special considerations for using Secondary Databases with and without Transactions

  Normally, during a primary database write operation (insert, update or delete), all associated secondary databases are also updated. However, when an exception occurs during the write operation, the updates may be incomplete. If the databases are transactional, this is handled by aborting the transaction to undo the incomplete operation. If an auto-commit transaction is used (null is passed for the transaction), the transaction will be aborted automatically. If an explicit transaction is used, it must be aborted by the application caller after the exception is caught.

  However, if the databases are non-transactional, integrity problems can result when an exception occurs during the write operation. Because the write operation is not made atomic by a transaction, references between the databases will become invalid if the operation is incomplete. This results in a {@link SecondaryIntegrityException} when attempting to access thedatabases later.

  A secondary integrity problem is persistent; it cannot be resolved by reopening the databases or the environment. The only way to resolve the problem is to restore the environment from a valid backup, or, if the integrity of the primary database is assumed, to remove and recreate all secondary databases.

  Therefore, secondary databases and indexes should always be used in conjunction with transactional databases and stores. Without transactions, it is the responsibility of the application to handle the results of the incomplete write operation or to take steps to prevent this situation from happening in the first place.

  The following exceptions may be thrown during a write operation, and may cause an integrity problem in the absence of transactions.

  • {@link SecondaryConstraintException}, see its subclasses for more information.
  • {@link LockConflictException}, when more than one thread is accessing the databases.
  • {@link EnvironmentFailureException}, if an unexpected or system failure occurs.
  • There is always the possibility of an {@link Error} or an unintended{@link RuntimeException}.

Related Classes of com.sleepycat.je.SecondaryDatabase