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 liquibase.database.jvm.JdbcConnection

    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
                }
                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")) {
                    liquibase.update("");
                }
                liquibase = new Liquibase("org/socialmusicdiscovery/server/database/sampledata/large/large.xml", new
                        ClassLoaderResourceAccessor(),
                        new JdbcConnection(connection));
                liquibase.update("");

                // Ensure that we don't delete the database contents
                System.setProperty("hibernate.hbm2ddl.auto", "validate");
                System.out.println("Starting to update search relations...");
    View Full Code Here

    Examples of liquibase.database.jvm.JdbcConnection

    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
       
        this.emUtil.doWork(new DsWork() {
          @Override
          public void execute(DataSource ds) {
            try (Connection conn = ds.getConnection()) {
              JdbcConnection jdbcConn = new JdbcConnection(conn);
             
              /*
               * The default implementation of Liquibase for Oracle has an error in the default Schema
               * lookup, so we'll set it here to avoid problems.
               */
     
    View Full Code Here

    Examples of liquibase.database.jvm.JdbcConnection

    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
       
        this.connUtil.doWork(new DbWork() {
          @Override
          public void execute(Connection conn) {
            try {
              JdbcConnection jdbcConn = new JdbcConnection(conn);
             
              /*
               * The default implementation of Liquibase for Oracle has an error in the default Schema
               * lookup, so we'll set it here to avoid problems.
               */
     
    View Full Code Here

    Examples of liquibase.database.jvm.JdbcConnection

    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
                Connection connection = null;
                try {

                    connection = dataSource.get().getConnection();
                    DatabaseConnection dc = new JdbcConnection( connection );
                    Liquibase liquibase = new Liquibase( config.get().changeLog().get(), new ClassLoaderResourceAccessor(), dc );
                    liquibase.update( config.get().contexts().get() );

                } catch ( SQLException e ) {
    View Full Code Here

    Examples of org.apache.manifoldcf.jdbc.JDBCConnection

    103
    104
    105
    106
    107
    108
    109
    110
          if (jdbcProvider == null || jdbcProvider.length() == 0)
            throw new ManifoldCFException("Missing parameter '"+JDBCConstants.providerParameter+"'");
          if ((host == null || host.length() == 0) && (rawDriverString == null || rawDriverString.length() == 0))
            throw new ManifoldCFException("Missing parameter '"+JDBCConstants.hostParameter+"' or '"+JDBCConstants.driverStringParameter+"'");

          connection = new JDBCConnection(jdbcProvider,(accessMethod==null || accessMethod.equals("name")),host,databaseName,rawDriverString,userName,password);
        }
      }
    View Full Code Here

    Examples of org.h2.jdbc.JdbcConnection

    931
    932
    933
    934
    935
    936
    937
            if (columnList) {
                url = Constants.CONN_URL_COLUMNLIST;
            } else {
                url = Constants.CONN_URL_INTERNAL;
            }
            return new JdbcConnection(this, getUser().getName(), url);
        }
    View Full Code Here

    Examples of org.h2.jdbc.JdbcConnection

    2256
    2257
    2258
    2259
    2260
    2261
    2262
    2263
    2264
            return lobStorage;
        }

        public Connection getLobConnection() {
            String url = Constants.CONN_URL_INTERNAL;
            JdbcConnection conn = new JdbcConnection(systemSession, systemUser.getName(), url);
            conn.setTraceLevel(TraceSystem.OFF);
            return conn;
        }
    View Full Code Here

    Examples of org.h2.jdbc.JdbcConnection

    228
    229
    230
    231
    232
    233
    234
    235
    236
    237
    238
    239
    240
    241
    242
    243
    244
    245
    246
    247
    248
    249
    250
    251
    252
    253
    254
    255
    256
    257
    258
    259
    260
    261
    262
    263
    264
    265
    266
    267
            conn.close();
        }

        private void testConcurrentCreate() throws Exception {
            deleteDb("lob");
            final JdbcConnection conn1 = (JdbcConnection) getConnection("lob");
            final JdbcConnection conn2 = (JdbcConnection) getConnection("lob");
            conn1.setAutoCommit(false);
            conn2.setAutoCommit(false);

            final byte[] buffer = new byte[10000];

            Task task1 = new Task() {
                public void call() throws Exception {
                    while (!stop) {
                        Blob b = conn1.createBlob();
                        OutputStream out = b.setBinaryStream(1);
                        out.write(buffer);
                        out.close();
                    }
                }
            };
            Task task2 = new Task() {
                public void call() throws Exception {
                    while (!stop) {
                        Blob b = conn2.createBlob();
                        OutputStream out = b.setBinaryStream(1);
                        out.write(buffer);
                        out.close();
                    }
                }
            };
            task1.execute();
            task2.execute();
            Thread.sleep(1000);
            task1.get();
            task2.get();
            conn1.close();
            conn2.close();
        }
    View Full Code Here

    Examples of org.h2.jdbc.JdbcConnection

    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
                IOUtils.rename(index, backupIndex);
                if (IOUtils.exists(lobs)) {
                    IOUtils.rename(lobs, backupLobs);
                }
                ci.removeProperty("IFEXISTS", false);
                conn = new JdbcConnection(ci, true);
                stat = conn.createStatement();
                if (cipher != null) {
                    stat.execute("runscript from '" + script + "' cipher aes password '" + uuid + "' --hide--");
                } else {
                    stat.execute("runscript from '" + script + "'");
    View Full Code Here

    Examples of org.h2.jdbc.JdbcConnection

    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
                }
                Connection c = DbUpgrade.connectOrUpgrade(url, info);
                if (c != null) {
                    return c;
                }
                return new JdbcConnection(url, info);
            } catch (Exception e) {
                throw DbException.toSQLException(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.