My intention is to use the specific client re-route Feature(see here) of the DB2 JDBC Driver. Therefore I have to pass some specific JDBC properties to the Reactive DB2 Client connection configuration.
When I try to pass the properties via:
DB2ConnectOptions connectOptions =
new DB2ConnectOptions()
.setPreparedStatementCacheMaxSize(dbConf.getPreparedStatementCacheMaxSize())
.setCachePreparedStatements(dbConf.isCachePreparedStatements())
.setPort(6000)
.setHost("host1")
.setDatabase(dbConf.getDatenbankName())
.setUser(dbConf.getBenutzer())
.setPassword(dbConf.getPasswort()) // won't take affect
.addProperty("enableClientAffinitiesList", "1") // won't take affect
.addProperty("clientRerouteAlternateServerName", "host2") // won't take affect
.addProperty("clientRerouteAlternatePortNumber", "5000"); // won't take affect
// Create the pooled sqlClient
var dbPool =
DB2Pool.client(
vertx,
connectOptions,
new PoolOptions()
.setMaxSize(dbConf.getPoolSize())
.setConnectionTimeout(dbConf.getConnectionTimeout())
.setPoolCleanerPeriod(dbConf.getPoolCleanerPeriod())
.setIdleTimeout(dbConf.getIdleTimeout()));
The properties doesn't be passed thought to the JDBC-Driver.
Does anybody know, if "io.vertx.db2client.DB2ConnectOptions#addProperty" is the right place to pass JDBC specific properties to the DB2 Driver
or is this functionality for the Reactive DB2 Client not available?
I hope anybody can help, kind regards :-)
Related
This question is for pg-promise, its recommended usage pattern & based on following assumption,
It does-not make sense to create more than a single pgp instance, if they are connecting to same DB(also enforced by the good warning message of "Creating a duplicate database object for the same connection.")
Given:
I have 2 individual packages which need DB connection, currently they take connection string in constructor from outside and create connection object inside them, which leads to the warning of duplicate connection object and is fair as they both talk to same DB and there is a possibility for optimisation here(since i am in control of those packages).
Then: To prevent this, i thought of implementing dependency injection, for which i pass a resolve function in libraries constructor which gives them the DB connection object.
Issue: There are some settings which are at top level like parsers and helpers and transaction modes which may be different for each of these packages what is the recommendation for such settings or is there a better patterns to address these issues.
EG:
const pg = require('pg-promise');
const instance = pg({"schema": "public"});
instance.pg.types.setTypeParser(1114, str => str);//UTC Date which one library requires other doesnt
const constring = "";
const resolveFunctionPackage1 = ()=>instance(constring);
const resolveFunctionPackage2 = ()=>instance(constring);
To sum up: What is the best way to implement dependency injection for pg-promise?
I have 2 individual packages which need DB connection, currently they take connection string in constructor from outside and create connection object inside them
That is a serious design flaw, and it's is never gonna work well. Any independent package that uses a database must be able to reuse an existing connection pool, which is the most valuable resource when it comes to connection usage. Head-on duplication of a connection pool inside an independent module will use up existing physical connections, and hinder performance of all other modules that need to use the same physical connection.
If a third-party library supports pg-promise, it should be able to accept instantiated db object for accessing the database.
And if the third-party library supports the base driver only, it should at least accept an instantiated Pool object. In pg-promise, db object exposes the underlying Pool object via db.$pool.
what happens when they want to set conflicting typeparsers?
There will be a conflict, because pg.types is a singleton from the underlying driver, so it can only be configured in one way. It is an unfortunate limitation.
The only way to avoid it, is for reusable modules to never re-configure the parsers. It should only be done within the actual client application.
UPDATE
Strictly speaking, one should avoid splitting a database-access layer of an application into multiple modules, there can be a number of problems to follow that.
But specifically for separation of type parsers, the library supports setting custom type parsers on the pool level. See example here. Note that the update is just for TypeScript, i.e. in JavaScript clients it has been working for awhile.
So you still can have your separate module create its own db object, but I would advise that you limit its connection pool size to the minimum then, like 1:
const moduleDb = pgp({
// ...connection details...
max: 1, // set pool size to just 1 connection
types: /* your custom type parsers */
});
I'm working on a Java/vertx project where the backend is MongoDB (I used to work with Elixir/Erlang since some time, and I'm quite new to vertx but I believe it's the best fit). Basically, I have an http API handled by some HttpServerVerticles which need to store data to (or retrieve data from) the mongo db and to send the appropriate reply to the API caller. I'm looking for the right pattern to implement the queries and the handling of the replies.
From the official guide and some tutorials, I see that for a relational JDBC database, it is necessary to define a dedicated verticle that will handle queries asynchronously. This was my first try with the mongo client but it introduces a lot of boilerplate.
On the other hand, from the mongo client documentation I read that it's Completely non-blocking and that it has its own connection pool. Does that mean that we can safely (from vertx event loop point of view), define and use the mongo client directly in the http verticle ?
Is there any alternative pattern ?
Versions : vertx:3.5.4 / mongodb:4.0.3
It's like that: mongo connection pool is exactly like SQL-db pool synchronous and blocking in it's nature, but is wrapped with non-blocking vert.x API around.
So, instead of a normal blocking way of
JsonObject obj = mongo.get( someQuery )
you have rather a non-blocking call out of the box:
mongo.findOne( 'collectionName', someQuery ){ AsyncResult<JsonObject> res ->
JsonObject obj = res.result()
doStuff( obj )
}
That means, that you can safely use it directly on the event-loop in any type of verticle without reinventing the asyncronous wheel over and over again.
At our client we use mongodb-driver-rx. Vertx has support for RX (vertx-rx-java) and it fits pretty well on mongodb-driver-rx.
For more information see:
https://mongodb.github.io/mongo-java-driver-rx/
https://vertx.io/docs/vertx-rx/java/
https://github.com/vert-x3/vertx-examples/blob/master/rxjava-2-examples/src/main/java/io/vertx/example/reactivex/database/mongo/Client.java
This page says I can put "clientProgramName" as one of the connection parameters and it will show up on db2 as the correlation ID.
And I quote:
In a java.util.Properties value in the info parameter of a
DriverManager.getConnection call.
We're using z/OS. The z/OS version of DB2 seems a lot more limited in terms of this kind of stuff.
Setting the client program name in the params hash of the connect call seems to have no effect, and when I put it on the end of the connect string url like this (which it also says I can do):
jdbc:db2://localhost:5036/DBNAME:clientProgramName=myprog
I get this error:
[jcc][10165][10051][4.11.77] Invalid database URL syntax:
jdbc:db2://localhost:5036/DBNAME:clientProgramName=myprog.
ERRORCODE=-4461, SQLSTATE=42815
Is there any way to send a custom user string to a z/OS db2 server so that connection can be identified on the server?
Depending on the method you use to connect to DB2, you use:
Class.forName
Class.forName("com.ibm.db2.jcc.DB2Driver");
Properties props = new Properties();
props.put("user", "scott");
props.put("password", "tiger");
props.put("clientProgramName", "My Program 1");
Connection conn = DriverManager.getConnection(
"jdbc:db2://localhost:50000/sample", props);
DataSource
Connection conn = null;
DB2SimpleDataSource ds = new com.ibm.db2.jcc.DB2SimpleDataSource();
ds.setDriverType(4);
ds.setServerName("localhost");
ds.setPortNumber(50000);
ds.setDatabaseName("sample");
ds.setUser("scott");
ds.setPassword("tiger");
ds.setClientProgramName("My Application 2");
conn = ds.getConnection();
I wrote a blog about that: http://angocadb2.blogspot.fr/2012/12/nombre-de-la-conexion-java-en-db2-java.html (Use your favorite translator because it is in Spanish)
According to this page on Info Center, there should be a function on the DB2Connection interface that allows you to change your application identifier, setDB2ClientApplicationInformation (I can't link directly, because there is no anchor, just search for that name).
You can pull the current application ID using the CURRENT CLIENT_APPLNAME special register:
SELECT CURRENT CLIENT_APPLNAME FROM SYSIBM.SYSDUMMY1
There are some other ways to set that register listed on the Info Center link listed above, including the WLM_SET_CLIENT_INFO function.
I am no DB2 expert, but I am looking at a trace record, generated by DB2 for z/OS, that contains a "correlation ID" (field QWHCCV in the product section correlation header of the trace record) that matches the value I set using setClientProgramName (method of the DB2 data source in my Java application).
My Java application is similar to the "DataSource" example given by AngocA, which is similar to the code quoted in the IBM technote 'The name of a DB2 JDBC application appears as "db2jcc_application". How to change it?'. This Java application, running on my Windows PC, connects to DB2 for z/OS. It also - and this is important, depending on which DB2 traces you have started (discussed below) - actually does something after connecting. For example:
pstmt=conn.prepareStatement("SELECT ... ");
rset=pstmt.executeQuery();
When you say, regarding the first example given by AngocA, "it doesn't do anything": what did you hope to see? Exactly where are you looking, what are you looking for, and what method (or tool) are you using to look for it?
For example, if you are looking for SMF type 100, 101, or 102 records (generated by DB2 traces) containing QWHCCV field values that match your correlation ID, then (with apologies if this is the bleeding obvious, teaching you how to suck eggs), on DB2 for z/OS, you need to start the DB2 traces (using the DB2 command START TRACE) that generate those records. Otherwise, there will be nothing to see ("it doesn't do anything"). Note that not all DB2 trace records generated by an application (such as the Java application described above) will contain your correlation ID; prior to a certain point in processing, the correlation ID of such records will have a different value (but that is getting off-topic, and anyway is about as far as I am comfortable describing).
Warning: Experiment with starting DB2 traces on a "sandbox" (development or test) DB2 system, not a production DB2 system. DB2 traces can result in large volumes of data.
You will also see the correlation ID in the message text of some DB2 V10 messages (such as DSNL027I) after "THREAD-INFO=".
For me I had to add a semicolon after each connection parameter.
EX for your case:
jdbc:db2://localhost:5036/DBNAME:clientProgramName=myprog;
EX with multiple params:
jdbc:db2://localhost:5036/DBNAME:clientProgramName=myprog;enableSysplexWLB=true;blah=true;
What are the analogies between the objects found in JDBC and the ones found in ADO.Net?
I know the object model in JDBC and ADO.Net are not exactly the same, but I think some analogies can be found among them (and key differences worth stating).
That would be useful for those who knows one API and wants to learn the other, serving as a starting point maybe, or avoiding misunderstandings caused by assumptions one makes about the API that wants to learn.
e.g.: Which is the ADO.Net object that provides the same functionality/behavior as the JDBC ResultSet? the same for PreparedStatemes, and so on...
Here is a simple sequence for ADO.NET:
// 1. create a connection
SqlConnection conn = new SqlConnection(xyz)
// 2. open the connection
conn.Open();
// 3. create a command
SqlCommand cmd = new SqlCommand("select * from xyz", conn);
// 4. execute and receive the result in a reader
SqlDataReader rdr = cmd.ExecuteReader();
// 5. get the results
while (rdr.Read())
{
//dosomething
}
Here is a simple sequence for JDBC:
// 1. create a connection
Connection con = DriverManager.getConnection(xyz);
// 2. create a statement
Statement stmt = con.createStatement();
// 3. execute and receive results in a result set
ResultSet rs = stmt.executeQuery("SELECT * from xyz");
// 4. Get the results
while (rs.next())
{
// do something
}
And here is the analogy (ADO.NET => JDBC):
SqlConnection => Connection
SqlCommand => Statement
SqlDataReader => ResultSet
Not very thorough with jdbc, but from what I know ADO.NET follows a disconnected architecture, where a connection is established only for the time a query has to be executed or read. Once the reader is read, connection can be closed. The data caching are achieved using datasets and data adapters. In ADO.NET only one reader is allowed per connection. While disconnected architecture is certainly possible in jdbc, its built on the concept of having live connection where you can have multiple readers per connection.
Another difference in the API is that there is built in functionality in jdbc to get the last inserted id, while ADO lacks one.
Also read a nice comparison on data caching in ADO and jdbc.
Is it possible to setup HSQLDB in a way, so that the files with the db information are written into memory instead of using actual files? I want to use hsqldb to export some data structures together with hibernate mappings. Is is, however, not possible to write temporary files, so that I need to generate the files in-memory and return a stream with their contents as a response.
Setting hsqldb to use nio seems not to be a solution, because there is no way to get hold of those files before they get written onto the filesystem.
What I'm thinking of is a protocol handler for hsqldb, but I didn't find a suitable solution yet.
Just to describe in other words: A hack solution would be to pass hsqldb a stream or several streams. It would then during its operation write data into those streams. After all data is written, the user of the db could then use those streams to send it back over the network.
Yes, of course, we use it all the time for integration testing.
use as url : jdbc:hsqldb:mem:aname
see here for more details
DbUnit offers a handy database dump method as part of their package :
// database connection
Class driverClass = Class.forName("org.hsqldb.jdbcDriver");
Connection jdbcConnection = DriverManager.getConnection(
"jdbc:hsqldb:sample", "sa", "");
IDatabaseConnection connection = new DatabaseConnection(jdbcConnection);
// full database export
IDataSet fullDataSet = connection.createDataSet();
FlatXmlDataSet.write(fullDataSet, new FileOutputStream("full.xml"));
see DbUnit FAQ for more details. Of course there are routines to restore the data, as that is actually the puropose of the package : prepare a test database for integration testing. Usually we do this with an annotation, but you'll have to use tha API for that.