Java DB

Apache Derby

Derby Developer's Guide

Derby Getting Started
Derby Reference Manual
Derby Developer's Guide
Derby Performance Tuning
Derby Server and Admin Guide
Derby Tools and Utilities
Derby Developer's Guide
-After installing

-The installation directory

-Batch files and shell scripts

-Derby and JVMs
-Derby libraries and classpath
-UNIX-specific issues

-Configuring file descriptors
-Scripts

-Preparing to upgrade
-Upgrading a database
-Soft upgrade limitations

-JDBC applications and Derby basics

-Application development overview
-Derby embedded basics

-Derby JDBC driver
-Derby JDBC database connection URL
-Derby system

-One Derby instance for each Java Virtual Machine (JVM)
-Booting databases
-Shutting down the system
-Defining the system directory
-The error log
-derby.properties
-Double-booting system behavior
-Recommended practices

-A Derby database

-The database directory
-Creating, dropping, and backing up databases
-Single database shutdown
-Storage and recovery
-Log on separate device
-Database pages
-Database-wide properties
-Derby database limitations

-Connecting to databases

-Connecting to databases within the system
-Connecting to databases outside the system directory
-Conventions for specifying the database path
-Special database access

-Database connection examples

-Working with the database connection URL attributes

-Using the databaseName attribute
-Shutting down Derby or an individual database
-Creating and accessing a database
-Providing a user name and password
-Creating a database with territory-based collation
-Encrypting a database when you create it
-Creating an encrypted database with an external key
-Specifying attributes in a properties object

-Using in-memory databases
-Working with Derby properties

-Properties overview

-Scope of properties
-Persistence of properties
-Precedence of properties

-Dynamic versus static properties

-Setting Derby properties

-Setting system-wide properties

-Setting database-wide properties
-Setting properties in a client/server environment
-Making dynamic or static changes to properties

-Properties case study

-Deploying Derby applications

-Deployment issues

-Embedded deployment application overview
-Deploying Derby in an embedded environment

-Embedded systems and properties

-Creating Derby databases for read-only use

-Creating and preparing the database for read-only use
-Deploying the database on the read-only media
-Transferring read-only databases to archive (jar or zip) files
-Accessing a read-only database in a zip/jar file
-Accessing databases within a jar file using the classpath

-Connecting to databases with ambiguous paths to databases in the file system
-Connecting to databases when the path is ambiguous because of databases in the classpath

-Databases on read-only media and DatabaseMetaData

-Loading classes from a database

-Class loading overview

-Create jar files for your application
-Add the jar file or files to the database

-Enable database class loading with a property
-Code your applications

-Dynamic changes to jar files or to the database jar classpath

-Requirements for dynamic changes
-Notes on dynamic changes

-Derby server-side programming

-Programming database-side JDBC routines

-Database-side JDBC routines and nested connections

-Requirements for database-side JDBC routines using nested connections

-Database-side JDBC routines using non-nested connections

-Invoking a procedure using the CALL command

-Database-side JDBC routines and SQLExceptions
-User-defined SQLExceptions

-Programming trigger actions

-Trigger action overview
-Performing referential actions
-Accessing before and after rows
-Examples of trigger actions
-Triggers and exceptions

-Aborting statements and transactions

-Programming Derby-style table functions

-Overview of Derby-style table functions

-Preferred getXXX() methods for Derby-style table functions

-Example Derby-style table function
-Writing restricted table functions
-Optimizer support for Derby-style table functions

-Measuring the cost of Derby-style table functions
-Example VTICosting implementation

-Programming user-defined types

-Controlling Derby application behavior

-The JDBC connection and transaction model

-Statements
-ResultSets and Cursors
-Nested connections

-Transactions when auto-commit is disabled
-Using auto-commit
-Turning off auto-commit
-Explicitly closing Statements, ResultSets, and Connections
-Statement versus transaction runtime rollback
-Using savepoints

-Result set and cursor mechanisms

-Simple non-updatable result sets

-Requirements for updatable result sets
-Forward only updatable result sets
-Scrollable updatable result sets
-Inserting rows with updatable result sets
-Naming or accessing the name of a cursor
-Extended updatable result set example

-Result sets and auto-commit
-Scrollable result sets
-Holdable result sets

-Holdable result sets and autocommit
-Non-holdable result set example

-Locking, concurrency, and isolation

-Isolation levels and concurrency
-Configuring isolation levels
-Lock granularity
-Types and scope of locks in Derby systems

-Exclusive locks
-Shared locks
-Update locks
-Lock compatibility
-Scope of locks
-Notes on locking

-Avoiding deadlocks
-Deadlock detection
-Lock wait timeouts
-Configuring deadlock detection and lock wait timeouts
-Debugging Deadlocks
-Programming applications to handle deadlocks

-Working with multiple connections to a single database

-Deployment options and threading and connection modes
-Multi-user database access
-Multiple connections from a single application

-Working with multiple threads sharing a single connection

-Pitfalls of sharing a connection among threads
-Multi-thread programming tips
-Example of threads sharing a

-Working with database threads in an embedded environment
-Working with Derby SQLExceptions in an application

-Information provided in SQL Exceptions

-Example of processing SQLExceptions

-Using Derby as a J2EE resource manager

-Classes that pertain to resource managers
-Getting a DataSource
-Shutting down or creating a database

-Derby and Security

-Configuring security for your environment

-Configuring security in a client/server environment
-Configuring security in an embedded environment

-Working with user authentication

-Enabling user authentication
-Defining users
-External directory service

-LDAP directory service

-JNDI-specific properties for external directory services
-User-defined class

-Built-in Derby users

-Database-level properties
-System-level properties

-List of user authentication properties
-Programming applications for Derby user authentication

-Programming the application to provide the user and password
-Login failure exceptions with user authentication

-Users and authorization identifiers

-Authorization identifiers, user authentication, and user authorization
-Database owner
-User names and schemas
-Exceptions when using authorization identifiers

-User authorizations

-Setting the default connection access mode
-Setting access for individual users

-Read-only and full access permissions
-User authorization exceptions

-Setting the SQL standard authorization mode

-Using SQL standard authorization
-Privileges on views, triggers, and constraints
-Using SQL roles
-SQL standard authorization exceptions

-Encrypting databases on disk

-Requirements for Derby encryption
-Working with encryption

-Encrypting databases on creation
-Encrypting an existing unencrypted database
-Creating the boot password

-Encrypting databases with a new key

-Booting an encrypted database

-Signed jar files
-Notes on the Derby security features
-User authentication and authorization examples

-User authentication example in a client/server environment

-User authentication and authorization client example

-User authentication example in a single-user, embedded environment

-User authentication and authorization embedded example

-User authentication examples using SQL authorization

-User authentication and SQL authorization client example
-User authentication and SQL authorization embedded example

-Running Derby under a security manager

-Granting permissions to Derby
-Examples of Java 2 security policy files for embedded Derby

-Java 2 security policy file example 1
-Java 2 security policy file example 2
-Java 2 security policy file example 3

-Developing tools and using Derby with an IDE

-Offering connection choices to the user

-The DriverPropertyInfo Array

-DriverPropertyInfo array example

-Using Derby with IDEs

-IDEs and multiple JVMs

-Retrieving the database connection URL
-Supplying a parameter only once
-Defining an identity column
-Using third-party tools
-Tricks of the VALUES clause

-Multiple rows
-Mapping column values to return values
-Creating empty queries

-Localizing Derby

-SQL parser support for Unicode
-Character-based collation in Derby
-Other components with locale support
-Messages libraries

-Derby and standards

-XML data types and operators

		Search documentation:

One Derby instance for each Java Virtual Machine (JVM) You could potentially have two instances of a Derby system running on the same machine at the same time. Each instance must run in a different Java Virtual Machine (JVM). If you use the embedded driver, two separate instances of Derby cannot access the same database. If a Derby instance attempts to access a running database, an error message appears, and a stack trace appears in the derby.log file. If you want more than one Derby instance to be able to access the same database, you can use the Network Server. If a Derby instance uses the in-memory database capability for its database connection, the database exists only within the JVM of that Derby instance. Another Derby instance could refer to the same database name, but it would not be referring to the same actual database, and no error would result. Parent topic: Derby system Related concepts Using Derby with IDEs

	javadb@jdbcurl.com