The JDBC Executor provides a fast and efficient means for accessing any JDBC-compliant data source over the Vertx 3.0 event bus. All interactions with the Executor are meant to be atomic and as 'short and sweet' as possible in order to minimize the contention on the shared (JDBC connection) resource; therefore no request/response behavior is supported. If you need that behavior, you should use the standard Vertx JDBC service.
The JDBC Executor relies on the high-performance HikariCP connection pool to maintain its connections. All of the configuration for this pool is contained with the 'pool' config entry, which is passed straight through to the HikariCP connection pool. Therefore for a full list of the configuration options, you should refer to the HikariCP Configuration.
An example of such a config is as follows:
{
address: "jdbc-pool",
dialect: "",
pool: {
jdbcUrl: "jdbc:hsqldb:mem:testdb",
username: "sa",
password: "",
minimumIdle: 5
}
}
The vertx address that you want to deploy this verticle to.
The (fully qualified class name of the) dialect of the JDBC driver. This class must be implement the com.vertx.jdbc.JdbcDialect interface. If not specified or left blank, the dialect defaults to "cstansbury.vertx.jdbc.dialect.BaseJdbcDialect".
The JDBC Executor relies on the high-performance HikariCP connection pool to manage its connections. All of the configuration for this pool is contained with the 'pool' config entry, which is passed straight through (untouched) to the HikariCP connection pool. Therefore for a full list of the configuration options, you should refer to the HikariCP Configuration.
The following actions are supported.
Not yet implemented.
Call some SQL that generates a ResultSet.
Takes an optional list of lists (same order as the ?
placeholders) as parameters to the query.
{
sql: "SELECT * FROM xxx"
}
or
{
sql: "SELECT * FROM xxx WHERE a=? AND b=?",
params: [ 10, 20 ]
}
or
{
sql: "SELECT * FROM xxx WHERE a=? AND b=?",
params: [[ 10, 20 ], [ 15, 25 ], ... ]
}
One of:
{
result: [ { "NAME":"a", "AGE":32 }, ... ]
}
Takes an optional list of lists (same order as the ?
placeholders) as parameters to the query.
Returns the primary keys generated by the insert.
You may also pass the optional parameters batchsize
and batchtimeout
if you want these keys returned in batches as with select
{
sql: "INSERT INTO xxx( a, b ) VALUES( ?, ? )",
params: [ [ 10, 20 ], ... ]
}
One of:
{
result: [ { "ID":1 }, { "ID":2 }, ... ]
updated: <nrows>
}
or
{
status: "error",
message: <message>
}
[{
"action": {
sql: "",
params: [ ]
}
},{
}]
This starts an SQL transaction, and returns a handler to execute any of the above messages inside.
After each response, if no reply is heard for more than timout
milliseconds (default 10000
), then the transaction is rolled back and the connection is closed.
Once you are done with a transaction, then handler needs to be sent a commit
or rollback
message (see below)
Inform the Transaction handler to commit any changes to the connection, and close the connection.
{
action: "commit"
}
Inform the Transaction handler to rollback any changes to the connection, and close the connection.