Examples of JdbcConnection

The {@link org.hsqldb.server.WebServer WebServer} database connection <url>takes one of two following forms:

  1. 'jdbc:hsqldb:http://host[:port][/<alias>][<key-value-pairs>]'
  2. 'jdbc:hsqldb:https://host[:port][/<alias>][<key-value-pairs>]' (with TLS).

In both network server database connection <url> forms, the optional <alias> component is used to identify one of possibly several database instances available at the indicated host and port. If the <alias> component is omitted, then a connection is made to the network server's default database instance, if such an instance is available.

For more information on server configuration regarding mounting multiple databases and assigning them <alias> values, please read the Java API documentation for {@link org.hsqldb.server.Server Server} and relatedchapters in the general documentation, especially the Advanced Users Guide.

Transient, In-Process Database Connections:

The 100% in-memory (transient, in-process) database connection <url> takes one of the two following forms:

  1. 'jdbc:hsqldb:.[<key-value-pairs>]' (the legacy form, extended)
  2. 'jdbc:hsqldb:mem:<alias>[<key-value-pairs>]' (the new form)

The driver converts the supplied <alias> component to Local.ENGLISH lower case and uses the resulting character sequence as the key used to look up a mem: protocol database instance amongst the collection of all such instances already in existence within the current class loading context in the current JVM. If no such instance exists, one may be automatically created and mapped to the <alias>, as governed by the 'ifexists=true|false' connection property.

The rationale for converting the supplied <alias> component to lower case is to provide consistency with the behavior of res: protocol database connection <url>s, explained further on in this overview.

Persistent, In-Process Database Connections:

The standalone (persistent, in-process) database connection <url> takes one of the three following forms:

  1. 'jdbc:hsqldb:<path>[<key-value-pairs>]' (the legacy form, extended)
  2. 'jdbc:hsqldb:file:<path>[<key-value-pairs>]' (same semantics as the legacy form)
  3. 'jdbc:hsqldb:res:<path>[<key-value-pairs>]' (new form with 'files_in_jar' semantics)

For the persistent, in-process database connection <url>, the <path> component is the path prefix common to all of the files that compose the database.

From 1.7.2, although other files may be involved (such as transient working files and/or TEXT table CSV data source files), the essential set that may, at any particular point in time, compose an HSQLDB database is:

For example: 'jdbc:hsqldb:file:test' connects to a database composed of some subset of the files listed above, where the expansion of <path> is 'test' prefixed with the canonical path of the JVM's effective working directory at the time the designated database is first opened in-process.

Be careful to note that this canonical expansion of <path> is cached by the driver until JVM exit. So, although legacy JVMs tend to fix the reported effective working directory at the one noted upon JVM startup, there is no guarantee that modern JVMs will continue to uphold this behaviour. What this means is there is effectively no guarantee into the future that a relative file: protocol database connection <url> will connect to the same database instance for the life of the JVM. To avoid any future ambigutity issues, it is probably a best practice for clients to attempt to pre-canonicalize the <path> component of file: protocol database connection* <url>s.

Under Windows TM , 'jdbc:hsqldb:file:c:\databases\test' connects to a database located on drive 'C:' in the directory 'databases', composed of some subset of the files: 

 C:\ +--databases\ +--test.properties +--test.script +--test.log +--test.data +--test.backup +--test.lck
Under most variations of UNIX, 'jdbc:hsqldb:file:/databases/test' connects to a database located in the directory 'databases' directly under root, once again composed of some subset of the files: 

 +--databases +--test.properties +--test.script +--test.log +--test.data +--test.backup +--test.lck
Some Guidelines:

  1. Both relative and absolute database file paths are supported.

  2. Relative database file paths can be specified in a platform independent manner as: '[dir1/dir2/.../dirn/]<file-name-prefix>'.

  3. Specification of absolute file paths is operating-system specific.
    Please read your OS file system documentation.

  4. Specification of network mounts may be operating-system specific.
    Please read your OS file system documentation.

  5. Special care may be needed w.r.t. file path specifications containing whitespace, mixed-case, special characters and/or reserved file names.
    Please read your OS file system documentation.

Note: Versions of HSQLDB previous to 1.7.0 did not support creating directories along the file path specified in the persistent, in-process mode database connection <url> form, in the case that they did not already exist. Starting with HSQLDB 1.7.0, directories will be created if they do not already exist., but only if HSQLDB is built under a version of the compiler greater than JDK 1.1.x.

res: protocol Connections:

The 'jdbc:hsqldb:res:<path>' database connection <url> has different semantics than the 'jdbc:hsqldb:file:<path>' form. The semantics are similar to those of a 'files_readonly' database, but with some additional points to consider.

Specifically, the '<path>' component of a res: protocol database connection <url> is first converted to lower case with Locale.ENGLISH and only then used to obtain resource URL objects, which in turn are used to read the database files as resources on the class path.

Due to lower case conversion by the driver, res: '<path>' components never find jar resources stored with Locale.ENGLISH mixed case paths. The rationale for converting to lower case is that not all pkzip implementations guarantee path case is preserved when archiving resources, and conversion to lower case seems to be the most common occurrence (although there is also no actual guarantee that the conversion is Locale.ENGLISH).

More importantly, res: '<path>' components must point only to resources contained in one or more jars on the class path. That is, only resources having the jar sub-protocol are considered valid.

This restriction is enforced to avoid the unfortunate situation in which, because res: database instances do not create a <path>.lck file (they are strictly files-read-only) and because the <path> components of res: and file: database URIs are not checked for file system equivalence, it is possible for the same database files to be accessed concurrently by both file: and res: database instances. That is, without this restriction, it is possible that <path>.data and <path>.properties file content may be written by a file: database instance without the knowlege or cooperation of a res: database instance open on the same files, potentially resulting in unexpected database errors, inconsistent operation and/or data corruption.

In short, a res: type database connection <url> is designed specifically to connect to a 'files_in_jar' mode database instance, which in turn is designed specifically to operate under Java WebStartTM and Java AppletTMconfigurations, where co-locating the database files in the jars that make up the WebStart application or Applet avoids the need for special security configuration or code signing.

Note: Since it is difficult and often nearly impossible to determine or control at runtime from where all classes are being loaded or which class loader is doing the loading (and hence how relative path specifications are resolved) under 'files_in_jar' semantics, the <path> component of the res: database connection <url> is always taken to be relative to the default package and resource URL resolution is always performed using the ClassLoader that loads the org.hsqldb.persist.Logger class. That is, if the <path> component does not start with '/', then'/' is prepended when obtaining the resource URLs used to read the database files, and only the effective class path of org.hsqldb.persist.Logger's ClassLoader is searched.

For more information about HSQLDB file structure, various database modes and other attributes such as those controlled through the HSQLDB properties files, please read the general documentation, especially the Advanced Users Guide.

JRE 1.1.x Notes:

In general, JDBC 2 support requires Java 1.2 and above, and JDBC3 requires Java 1.4 and above. In HSQLDB, support for methods introduced in different versions of JDBC depends on the JDK version used for compiling and building HSQLDB.

Since 1.7.0, it is possible to build the product so that all JDBC 2 methods can be called while executing under the version 1.1.x Java Runtime EnvironmentTM. However, in addition to this technique requiring explicit casts to the org.hsqldb.jdbc.* classes, some of the method calls also require int values that are defined only in the JDBC 2 or greater version of the {@link java.sql.ResultSet ResultSet} interface. For thisreason, when the product is compiled under JDK 1.1.x, these values are defined in {@link JDBCResultSet JDBCResultSet}.

In a JRE 1.1.x environment, calling JDBC 2 methods that take or return the JDBC 2+ ResultSet values can be achieved by referring to them in parameter specifications and return value comparisons, respectively, as follows: 

 JDBCResultSet.FETCH_FORWARD JDBCResultSet.TYPE_FORWARD_ONLY JDBCResultSet.TYPE_SCROLL_INSENSITIVE JDBCResultSet.CONCUR_READ_ONLY // etc.
However, please note that code written to use HSQLDB JDBC 2 features under JDK 1.1.x will not be compatible for use with other JDBC 2 drivers. Please also note that this feature is offered solely as a convenience to developers who must work under JDK 1.1.x due to operating constraints, yet wish to use some of the more advanced features available under the JDBC 2 specification.

JDBC 4.0 Notes:

Starting with JDBC 4.0 (JDK 1.6), the DriverManager methods getConnection and getDrivers have been enhanced to support the Java Standard Edition Service Provider mechanism. When built under a Java runtime that supports JDBC 4.0, HSQLDB distribution jars containing the Driver implementatiton also include the file META-INF/services/java.sql.Driver. This file contains the fully qualified class name ('org.hsqldb.jdbc.JDBCDriver') of the HSQLDB implementation of java.sql.Driver.

Hence, under JDBC 4.0 or greater, applications no longer need to explictly load the HSQLDB JDBC driver using Class.forName(). Of course, existing programs which do load JDBC drivers using Class.forName() will continue to work without modification.

(fredt@users)
(boucherb@users)

@author Campbell Boucher-Burnett (boucherb@users dot sourceforge.net) @author Fred Toussi (fredt@users dot sourceforge.net) @version 2.0 @revised JDK 1.6, HSQLDB 2.0 @see JDBCDriver @see JDBCStatement @see JDBCParameterMetaData @see JDBCCallableStatement @see JDBCResultSet @see JDBCDatabaseMetaData @see java.sql.DriverManager#getConnection @see java.sql.Statement @see java.sql.ResultSet @see java.sql.DatabaseMetaData

  • org.hsqldb.jdbc.jdbcConnection
    :port][/<alias>][<key-value-pairs>]'
  • 'jdbc:hsqldb:hsqls://host[:port][/<alias>][<key-value-pairs>]' (with TLS).

    The {@link org.hsqldb.server.WebServer WebServer} database connection <url>takes one of two following forms:

    1. 'jdbc:hsqldb:http://host[:port][/<alias>][<key-value-pairs>]'
    2. 'jdbc:hsqldb:https://host[:port][/<alias>][<key-value-pairs>]' (with TLS).

    In both network server database connection <url> forms, the optional <alias> component is used to identify one of possibly several database instances available at the indicated host and port. If the <alias> component is omitted, then a connection is made to the network server's default database instance, if such an instance is available.

    For more information on server configuration regarding mounting multiple databases and assigning them <alias> values, please read the Java API documentation for {@link org.hsqldb.server.Server Server} and relatedchapters in the general documentation, especially the Advanced Users Guide.

    Transient, In-Process Database Connections:

    The 100% in-memory (transient, in-process) database connection <url> takes one of the two following forms:

    1. 'jdbc:hsqldb:.[<key-value-pairs>]' (the legacy form, extended)
    2. 'jdbc:hsqldb:mem:<alias>[<key-value-pairs>]' (the new form)

    The driver converts the supplied <alias> component to Local.ENGLISH lower case and uses the resulting character sequence as the key used to look up a mem: protocol database instance amongst the collection of all such instances already in existence within the current class loading context in the current JVM. If no such instance exists, one may be automatically created and mapped to the <alias>, as governed by the 'ifexists=true|false' connection property.

    The rationale for converting the supplied <alias> component to lower case is to provide consistency with the behavior of res: protocol database connection <url>s, explained further on in this overview.

    Persistent, In-Process Database Connections:

    The standalone (persistent, in-process) database connection <url> takes one of the three following forms:

    1. 'jdbc:hsqldb:<path>[<key-value-pairs>]' (the legacy form, extended)
    2. 'jdbc:hsqldb:file:<path>[<key-value-pairs>]' (same semantics as the legacy form)
    3. 'jdbc:hsqldb:res:<path>[<key-value-pairs>]' (new form with 'files_in_jar' semantics)

    For the persistent, in-process database connection <url>, the <path> component is the path prefix common to all of the files that compose the database.

    From 1.7.2, although other files may be involved (such as transient working files and/or TEXT table CSV data source files), the essential set that may, at any particular point in time, compose an HSQLDB database is:

    For example: 'jdbc:hsqldb:file:test' connects to a database composed of some subset of the files listed above, where the expansion of <path> is 'test' prefixed with the canonical path of the JVM's effective working directory at the time the designated database is first opened in-process.

    Be careful to note that this canonical expansion of <path> is cached by the driver until JVM exit. So, although legacy JVMs tend to fix the reported effective working directory at the one noted upon JVM startup, there is no guarantee that modern JVMs will continue to uphold this behaviour. What this means is there is effectively no guarantee into the future that a relative file: protocol database connection <url> will connect to the same database instance for the life of the JVM. To avoid any future ambigutity issues, it is probably a best practice for clients to attempt to pre-canonicalize the <path> component of file: protocol database connection* <url>s.

    Under Windows TM , 'jdbc:hsqldb:file:c:\databases\test' connects to a database located on drive 'C:' in the directory 'databases', composed of some subset of the files: 

     C:\ +--databases\ +--test.properties +--test.script +--test.log +--test.data +--test.backup +--test.lck
    Under most variations of UNIX, 'jdbc:hsqldb:file:/databases/test' connects to a database located in the directory 'databases' directly under root, once again composed of some subset of the files: 

     +--databases +--test.properties +--test.script +--test.log +--test.data +--test.backup +--test.lck
    Some Guidelines:

    1. Both relative and absolute database file paths are supported.

    2. Relative database file paths can be specified in a platform independent manner as: '[dir1/dir2/.../dirn/]<file-name-prefix>'.

    3. Specification of absolute file paths is operating-system specific.
      Please read your OS file system documentation.

    4. Specification of network mounts may be operating-system specific.
      Please read your OS file system documentation.

    5. Special care may be needed w.r.t. file path specifications containing whitespace, mixed-case, special characters and/or reserved file names.
      Please read your OS file system documentation.

    Note: Versions of HSQLDB previous to 1.7.0 did not support creating directories along the file path specified in the persistent, in-process mode database connection <url> form, in the case that they did not already exist. Starting with HSQLDB 1.7.0, directories will be created if they do not already exist., but only if HSQLDB is built under a version of the compiler greater than JDK 1.1.x.

    res: protocol Connections:

    The 'jdbc:hsqldb:res:<path>' database connection <url> has different semantics than the 'jdbc:hsqldb:file:<path>' form. The semantics are similar to those of a 'files_readonly' database, but with some additional points to consider.

    Specifically, the '<path>' component of a res: protocol database connection <url> is first converted to lower case with Locale.ENGLISH and only then used to obtain resource URL objects, which in turn are used to read the database files as resources on the class path.

    Due to lower case conversion by the driver, res: '<path>' components never find jar resources stored with Locale.ENGLISH mixed case paths. The rationale for converting to lower case is that not all pkzip implementations guarantee path case is preserved when archiving resources, and conversion to lower case seems to be the most common occurrence (although there is also no actual guarantee that the conversion is Locale.ENGLISH).

    More importantly, res: '<path>' components must point only to resources contained in one or more jars on the class path. That is, only resources having the jar sub-protocol are considered valid.

    This restriction is enforced to avoid the unfortunate situation in which, because res: database instances do not create a <path>.lck file (they are strictly files-read-only) and because the <path> components of res: and file: database URIs are not checked for file system equivalence, it is possible for the same database files to be accessed concurrently by both file: and res: database instances. That is, without this restriction, it is possible that <path>.data and <path>.properties file content may be written by a file: database instance without the knowlege or cooperation of a res: database instance open on the same files, potentially resulting in unexpected database errors, inconsistent operation and/or data corruption.

    In short, a res: type database connection <url> is designed specifically to connect to a 'files_in_jar' mode database instance, which in turn is designed specifically to operate under Java WebStartTM and Java AppletTMconfigurations, where co-locating the database files in the jars that make up the WebStart application or Applet avoids the need for special security configuration or code signing.

    Note: Since it is difficult and often nearly impossible to determine or control at runtime from where all classes are being loaded or which class loader is doing the loading (and hence how relative path specifications are resolved) under 'files_in_jar' semantics, the <path> component of the res: database connection <url> is always taken to be relative to the default package and resource URL resolution is always performed using the ClassLoader that loads the org.hsqldb.persist.Logger class. That is, if the <path> component does not start with '/', then'/' is prepended when obtaining the resource URLs used to read the database files, and only the effective class path of org.hsqldb.persist.Logger's ClassLoader is searched.

    For more information about HSQLDB file structure, various database modes and other attributes such as those controlled through the HSQLDB properties files, please read the general documentation, especially the Advanced Users Guide.

    JRE 1.1.x Notes:

    In general, JDBC 2 support requires Java 1.2 and above, and JDBC3 requires Java 1.4 and above. In HSQLDB, support for methods introduced in different versions of JDBC depends on the JDK version used for compiling and building HSQLDB.

    Since 1.7.0, it is possible to build the product so that all JDBC 2 methods can be called while executing under the version 1.1.x Java Runtime EnvironmentTM. However, in addition to this technique requiring explicit casts to the org.hsqldb.jdbc.* classes, some of the method calls also require int values that are defined only in the JDBC 2 or greater version of the {@link java.sql.ResultSet ResultSet} interface. For thisreason, when the product is compiled under JDK 1.1.x, these values are defined in {@link JDBCResultSet JDBCResultSet}.

    In a JRE 1.1.x environment, calling JDBC 2 methods that take or return the JDBC 2+ ResultSet values can be achieved by referring to them in parameter specifications and return value comparisons, respectively, as follows: 

     JDBCResultSet.FETCH_FORWARD JDBCResultSet.TYPE_FORWARD_ONLY JDBCResultSet.TYPE_SCROLL_INSENSITIVE JDBCResultSet.CONCUR_READ_ONLY // etc.
    However, please note that code written to use HSQLDB JDBC 2 features under JDK 1.1.x will not be compatible for use with other JDBC 2 drivers. Please also note that this feature is offered solely as a convenience to developers who must work under JDK 1.1.x due to operating constraints, yet wish to use some of the more advanced features available under the JDBC 2 specification.

    JDBC 4.0 Notes:

    Starting with JDBC 4.0 (JDK 1.6), the DriverManager methods getConnection and getDrivers have been enhanced to support the Java Standard Edition Service Provider mechanism. When built under a Java runtime that supports JDBC 4.0, HSQLDB distribution jars containing the Driver implementatiton also include the file META-INF/services/java.sql.Driver. This file contains the fully qualified class name ('org.hsqldb.jdbc.JDBCDriver') of the HSQLDB implementation of java.sql.Driver.

    Hence, under JDBC 4.0 or greater, applications no longer need to explictly load the HSQLDB JDBC driver using Class.forName(). Of course, existing programs which do load JDBC drivers using Class.forName() will continue to work without modification.

    (fredt@users)
    (boucherb@users)

    @author Campbell Boucher-Burnett (boucherb@users dot sourceforge.net) @author Fred Toussi (fredt@users dot sourceforge.net) @version 2.0 @revised JDK 1.6, HSQLDB 2.0 @see JDBCDriver @see JDBCStatement @see JDBCParameterMetaData @see JDBCCallableStatement @see JDBCResultSet @see JDBCDatabaseMetaData @see java.sql.DriverManager#getConnection @see java.sql.Statement @see java.sql.ResultSet @see java.sql.DatabaseMetaData

  • org.hsqldb_voltpatches.jdbc.JDBCConnection
    :port][/<alias>][<key-value-pairs>]'
  • 'jdbc:hsqldb:hsqls://host[:port][/<alias>][<key-value-pairs>]' (with TLS).

    The {@link org.hsqldb_voltpatches.server.WebServer WebServer} database connection <url>takes one of two following forms:

    1. 'jdbc:hsqldb:http://host[:port][/<alias>][<key-value-pairs>]'
    2. 'jdbc:hsqldb:https://host[:port][/<alias>][<key-value-pairs>]' (with TLS).

    In both network server database connection <url> forms, the optional <alias> component is used to identify one of possibly several database instances available at the indicated host and port. If the <alias> component is omitted, then a connection is made to the network server's default database instance, if such an instance is available.

    For more information on server configuration regarding mounting multiple databases and assigning them <alias> values, please read the Java API documentation for {@link org.hsqldb_voltpatches.server.Server Server} and relatedchapters in the general documentation, especially the Advanced Users Guide.

    Transient, In-Process Database Connections:

    The 100% in-memory (transient, in-process) database connection <url> takes one of the two following forms:

    1. 'jdbc:hsqldb:.[<key-value-pairs>]' (the legacy form, extended)
    2. 'jdbc:hsqldb:mem:<alias>[<key-value-pairs>]' (the new form)

    The driver converts the supplied <alias> component to Local.ENGLISH lower case and uses the resulting character sequence as the key used to look up a mem: protocol database instance amongst the collection of all such instances already in existence within the current class loading context in the current JVM. If no such instance exists, one may be automatically created and mapped to the <alias>, as governed by the 'ifexists=true|false' connection property.

    The rationale for converting the supplied <alias> component to lower case is to provide consistency with the behavior of res: protocol database connection <url>s, explained further on in this overview.

    Persistent, In-Process Database Connections:

    The standalone (persistent, in-process) database connection <url> takes one of the three following forms:

    1. 'jdbc:hsqldb:<path>[<key-value-pairs>]' (the legacy form, extended)
    2. 'jdbc:hsqldb:file:<path>[<key-value-pairs>]' (same semantics as the legacy form)
    3. 'jdbc:hsqldb:res:<path>[<key-value-pairs>]' (new form with 'files_in_jar' semantics)

    For the persistent, in-process database connection <url>, the <path> component is the path prefix common to all of the files that compose the database.

    From 1.7.2, although other files may be involved (such as transient working files and/or TEXT table CSV data source files), the essential set that may, at any particular point in time, compose an HSQLDB database is:

    For example: 'jdbc:hsqldb:file:test' connects to a database composed of some subset of the files listed above, where the expansion of <path> is 'test' prefixed with the canonical path of the JVM's effective working directory at the time the designated database is first opened in-process.

    Be careful to note that this canonical expansion of <path> is cached by the driver until JVM exit. So, although legacy JVMs tend to fix the reported effective working directory at the one noted upon JVM startup, there is no guarantee that modern JVMs will continue to uphold this behaviour. What this means is there is effectively no guarantee into the future that a relative file: protocol database connection <url> will connect to the same database instance for the life of the JVM. To avoid any future ambigutity issues, it is probably a best practice for clients to attempt to pre-canonicalize the <path> component of file: protocol database connection* <url>s.

    Under Windows TM , 'jdbc:hsqldb:file:c:\databases\test' connects to a database located on drive 'C:' in the directory 'databases', composed of some subset of the files: 

     C:\ +--databases\ +--test.properties +--test.script +--test.log +--test.data +--test.backup +--test.lck
    Under most variations of UNIX, 'jdbc:hsqldb:file:/databases/test' connects to a database located in the directory 'databases' directly under root, once again composed of some subset of the files: 

     +--databases +--test.properties +--test.script +--test.log +--test.data +--test.backup +--test.lck
    Some Guidelines:

    1. Both relative and absolute database file paths are supported.

    2. Relative database file paths can be specified in a platform independent manner as: '[dir1/dir2/.../dirn/]<file-name-prefix>'.

    3. Specification of absolute file paths is operating-system specific.
      Please read your OS file system documentation.

    4. Specification of network mounts may be operating-system specific.
      Please read your OS file system documentation.

    5. Special care may be needed w.r.t. file path specifications containing whitespace, mixed-case, special characters and/or reserved file names.
      Please read your OS file system documentation.

    Note: Versions of HSQLDB previous to 1.7.0 did not support creating directories along the file path specified in the persistent, in-process mode database connection <url> form, in the case that they did not already exist. Starting with HSQLDB 1.7.0, directories will be created if they do not already exist., but only if HSQLDB is built under a version of the compiler greater than JDK 1.1.x.

    res: protocol Connections:

    The 'jdbc:hsqldb:res:<path>' database connection <url> has different semantics than the 'jdbc:hsqldb:file:<path>' form. The semantics are similar to those of a 'files_readonly' database, but with some additional points to consider.

    Specifically, the '<path>' component of a res: protocol database connection <url> is first converted to lower case with Locale.ENGLISH and only then used to obtain resource URL objects, which in turn are used to read the database files as resources on the class path.

    Due to lower case conversion by the driver, res: '<path>' components never find jar resources stored with Locale.ENGLISH mixed case paths. The rationale for converting to lower case is that not all pkzip implementations guarantee path case is preserved when archiving resources, and conversion to lower case seems to be the most common occurrence (although there is also no actual guarantee that the conversion is Locale.ENGLISH).

    More importantly, res: '<path>' components must point only to resources contained in one or more jars on the class path. That is, only resources having the jar sub-protocol are considered valid.

    This restriction is enforced to avoid the unfortunate situation in which, because res: database instances do not create a <path>.lck file (they are strictly files-read-only) and because the <path> components of res: and file: database URIs are not checked for file system equivalence, it is possible for the same database files to be accessed concurrently by both file: and res: database instances. That is, without this restriction, it is possible that <path>.data and <path>.properties file content may be written by a file: database instance without the knowlege or cooperation of a res: database instance open on the same files, potentially resulting in unexpected database errors, inconsistent operation and/or data corruption.

    In short, a res: type database connection <url> is designed specifically to connect to a 'files_in_jar' mode database instance, which in turn is designed specifically to operate under Java WebStartTM and Java AppletTMconfigurations, where co-locating the database files in the jars that make up the WebStart application or Applet avoids the need for special security configuration or code signing.

    Note: Since it is difficult and often nearly impossible to determine or control at runtime from where all classes are being loaded or which class loader is doing the loading (and hence how relative path specifications are resolved) under 'files_in_jar' semantics, the <path> component of the res: database connection <url> is always taken to be relative to the default package and resource URL resolution is always performed using the ClassLoader that loads the org.hsqldb_voltpatches.persist.Logger class. That is, if the <path> component does not start with '/', then'/' is prepended when obtaining the resource URLs used to read the database files, and only the effective class path of org.hsqldb_voltpatches.persist.Logger's ClassLoader is searched.

    For more information about HSQLDB file structure, various database modes and other attributes such as those controlled through the HSQLDB properties files, please read the general documentation, especially the Advanced Users Guide.

    JRE 1.1.x Notes:

    In general, JDBC 2 support requires Java 1.2 and above, and JDBC3 requires Java 1.4 and above. In HSQLDB, support for methods introduced in different versions of JDBC depends on the JDK version used for compiling and building HSQLDB.

    Since 1.7.0, it is possible to build the product so that all JDBC 2 methods can be called while executing under the version 1.1.x Java Runtime EnvironmentTM. However, in addition to this technique requiring explicit casts to the org.hsqldb_voltpatches.jdbc.* classes, some of the method calls also require int values that are defined only in the JDBC 2 or greater version of the {@link java.sql.ResultSet ResultSet} interface. For thisreason, when the product is compiled under JDK 1.1.x, these values are defined in {@link JDBCResultSet JDBCResultSet}.

    In a JRE 1.1.x environment, calling JDBC 2 methods that take or return the JDBC 2+ ResultSet values can be achieved by referring to them in parameter specifications and return value comparisons, respectively, as follows: 

     JDBCResultSet.FETCH_FORWARD JDBCResultSet.TYPE_FORWARD_ONLY JDBCResultSet.TYPE_SCROLL_INSENSITIVE JDBCResultSet.CONCUR_READ_ONLY // etc.
    However, please note that code written to use HSQLDB JDBC 2 features under JDK 1.1.x will not be compatible for use with other JDBC 2 drivers. Please also note that this feature is offered solely as a convenience to developers who must work under JDK 1.1.x due to operating constraints, yet wish to use some of the more advanced features available under the JDBC 2 specification.

    JDBC 4.0 Notes:

    Starting with JDBC 4.0 (JDK 1.6), the DriverManager methods getConnection and getDrivers have been enhanced to support the Java Standard Edition Service Provider mechanism. When built under a Java runtime that supports JDBC 4.0, HSQLDB distribution jars containing the Driver implementatiton also include the file META-INF/services/java.sql.Driver. This file contains the fully qualified class name ('org.hsqldb_voltpatches.jdbc.JDBCDriver') of the HSQLDB implementation of java.sql.Driver.

    Hence, under JDBC 4.0 or greater, applications no longer need to explictly load the HSQLDB JDBC driver using Class.forName(). Of course, existing programs which do load JDBC drivers using Class.forName() will continue to work without modification.

    (fredt@users)
    (boucherb@users)

    @author Campbell Boucher-Burnett (boucherb@users dot sourceforge.net) @author Fred Toussi (fredt@users dot sourceforge.net) @version 1.9.0 @revised JDK 1.6, HSQLDB 1.9.0 @see JDBCDriver @see JDBCStatement @see JDBCParameterMetaData @see JDBCCallableStatement @see JDBCResultSet @see JDBCDatabaseMetaData @see java.sql.DriverManager#getConnection @see java.sql.Statement @see java.sql.ResultSet @see java.sql.DatabaseMetaData

  • org.lealone.jdbc.JdbcConnection

    Represents a connection (session) to a database.

    Thread safety: the connection is thread-safe, because access is synchronized. However, for compatibility with other databases, a connection should only be used in one thread at any time.

    • Examples of com.fathomdb.jdbc.JdbcConnection

    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
      @Override
      @JdbcTransaction
      public ServiceAuthorization findServiceAuthorization(ServiceType serviceType, ProjectId project)
          throws RepositoryException {
        try {
          JdbcConnection connection = connectionProvider.get();
          int serviceId = JdbcRepositoryHelpers.getServiceKey(connection, serviceType);
          int projectId = JdbcRepositoryHelpers.getProjectKey(connection, project);

          String sql = "SELECT data FROM service_authorizations WHERE service=? and project=?";

          List<ServiceAuthorization> items = Lists.newArrayList();

          PreparedStatement ps = connection.prepareStatement(sql);
          ResultSet rs = null;
          try {
            ps.setInt(1, serviceId);
            ps.setInt(2, projectId);
            rs = ps.executeQuery();
    View Full Code Here

    Examples of com.fathomdb.jdbc.JdbcConnection

    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
      public ServiceAuthorization createAuthorization(ProjectId project, ServiceAuthorization authorization)
          throws RepositoryException {
        try {
          ServiceType serviceType = new ServiceType(authorization.serviceType);

          JdbcConnection connection = connectionProvider.get();
          int serviceId = JdbcRepositoryHelpers.getServiceKey(connection, serviceType);
          int projectId = JdbcRepositoryHelpers.getProjectKey(connection, project);

          final String sql = "INSERT INTO service_authorizations (service, project, data) VALUES (?, ?, ?)";

          PreparedStatement ps = connection.prepareStatement(sql);
          ResultSet rs = null;
          try {
            ps.setInt(1, serviceId);
            ps.setInt(2, projectId);
            ps.setString(3, authorization.data);
    View Full Code Here

    Examples of com.googlecode.g2re.domain.JdbcConnection

    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
        }
       
        public JdbcConnection getJdbcConnection() {

            /* Create the first data source */
            JdbcConnection source1 = new JdbcConnection();
            source1.setName("PetStoreDataSource");
            source1.setDatabaseJndiName("jndi/PetStoreDataSource");
            source1.setDatabaseUser(DB_USER);
            source1.setDatabasePassword(DB_PW);
            source1.setDriverClass(CLASS_NAME);
            source1.setDatabaseUrl(DB_URL);

            return source1;
        }
    View Full Code Here

    Examples of com.jengine.orm.db.adapter.jdbc.JDBCConnection

    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
            this.dataSource = dataSource;
        }

        public DBConnection getConnection() throws DBException {
            try {
                return new JDBCConnection(this.dataSource.getConnection());
            } catch (Exception e) {
                throw new DBException(e);
            }
        }
    View Full Code Here

    Examples of com.jengine.orm.db.adapter.jdbc.JDBCConnection

    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
            }
        }

        public DBConnection getConnection() throws DBException {
            try {
                return new JDBCConnection(DriverManager.getConnection(this.connection, this.user, this.password));
            } catch (Exception e) {
                e.printStackTrace();
                throw new DBException(e);
            }
        }
    View Full Code Here

    Examples of it.eng.spagobi.jpivotaddins.engines.jpivotxmla.connection.JDBCConnection

    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
          if(connectionType == null) {
            logger.error("Attribute 'type' of connection " + connectionName + " is not setted");
          }else if(connectionType.equalsIgnoreCase("jndi")) {
            connection = new JNDIConnection(connSb);
          } else if (connectionType.equalsIgnoreCase("jdbc")) {
            connection = new JDBCConnection(connSb);
          } else if (connectionType.equalsIgnoreCase("xmla")) {
            connection = new XMLAConnection(connSb);
          } else {
            logger.error("Value '"+  connectionType +"' in not a valid value for attribute 'type' in connection " + connectionName);
          }
    View Full Code Here

    Examples of liquibase.database.jvm.JdbcConnection

    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
                }
                provider.start();
                Connection connection = provider.getConnection();
                Liquibase liquibase = new Liquibase("org/socialmusicdiscovery/server/database/smd-database.changelog.xml", new
                        ClassLoaderResourceAccessor(),
                        new JdbcConnection(connection));
                if (System.getProperty("liquibase") == null || !System.getProperty("liquibase").equals("false")) {
                    // If database is locked, retry 10 times before we give up and force the lock to be released
                    for(int i=0;i<10 && liquibase.listLocks().length>0;i++) {
                        Thread.sleep(1000);
                    }
    View Full Code Here

    Examples of liquibase.database.jvm.JdbcConnection

    162
    163
    164
    165
    166
    167
    168
    169
    170
    171
    172
    173
    174
    175
    176
                DatabaseProvider provider = InjectHelper.instanceWithName(DatabaseProvider.class, database);
                try {
                    Connection connection = provider.getConnection();
                    Liquibase liquibase = new Liquibase("org/socialmusicdiscovery/server/database/smd-database-drop.xml", new
                            ClassLoaderResourceAccessor(),
                            new JdbcConnection(connection));
                    liquibase.update("");
                    liquibase = new Liquibase("org/socialmusicdiscovery/server/database/smd-database.changelog.xml", new
                            ClassLoaderResourceAccessor(),
                            new JdbcConnection(connection));
                    liquibase.update("");
                } catch (LiquibaseException e) {
                    e.printStackTrace();
                    progressHandler.failed(getId(), e.getLocalizedMessage());
                    return;
    View Full Code Here

    Examples of liquibase.database.jvm.JdbcConnection

    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
        void execute(Connection connection) throws PluginException {
            try {
                Liquibase liquibase = new Liquibase("org/socialmusicdiscovery/server/database/sampledata/smd-database.sampledata.xml", new
                        ClassLoaderResourceAccessor(),
                        new JdbcConnection(connection));
                liquibase.update("");
            } catch (LiquibaseException e) {
                e.printStackTrace();
                throw new PluginException(getClass().getSimpleName() + " failure", e);
            }
    View Full Code Here

    Examples of liquibase.database.jvm.JdbcConnection

    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
            try {
                progressHandler.progress(getId(),"Deleting database contents",1L,2L);
                Connection connection = provider.getConnection();
                Liquibase liquibase = new Liquibase("org/socialmusicdiscovery/server/database/smd-database-drop.xml", new
                        ClassLoaderResourceAccessor(),
                        new JdbcConnection(connection));
                liquibase.update("");
                progressHandler.progress(getId(), "Creating fresh database", 2L, 2L);
                liquibase = new Liquibase("org/socialmusicdiscovery/server/database/smd-database.changelog.xml", new
                        ClassLoaderResourceAccessor(),
                        new JdbcConnection(connection));
                liquibase.update("");
                progressHandler.finished(getId());
            } catch (LiquibaseException e) {
                progressHandler.failed(getId(),e.getMessage());
            } catch (SQLException e) {
    View Full Code Here
    TOP
    Copyright © 2018 www.massapi.com. All rights reserved.
    All source code are property of their respective owners. Java is a trademark of Sun Microsystems, Inc and owned by ORACLE Inc. Contact coftware#gmail.com.