Since working with databases requires input/output, may take unbounded amount of time, etc. it seems natural to want a non-blocking, asynchronous API. Is there one for Java?
I do not think that such API exists but there are 2 different things: DB access libraries and a lot of ways to perform asynchronous calls in java.
You can use either plain JDBC or any other higher level tool that simplifies DB access implementation to access your database.
You can make asynchronous calls using JMS (if you are in Java EE environment) or using queues and executors from concurrency package if your are in JSE environment. Obviously a lot of other solutions available too.
There is no standard API like JBDC which would allow you to asynchronously call any DB. However there is this Google Project which tries to do exactly this for PostgreSQL and MySQL.
You may also take a look at this question, which addresses similar stuff:
Is asynchronous jdbc call possible?
For Couchbase I came across Reactive Couchbase which claims to do this and has a Java Wrapper. Didn't try it but there are several examples in the links.
Related
I have a requirement where I have to persist some data in a table and the persisting may take sometime. Basically I want to persist a log. I don't want the execution to wait till the persisting finishes.
I know I have to use threads to accomplish this task and I know that it is discouraged to create threads in an enterprise application.
So I started reading about worker manager and understood and tried a sample program in websphere application server 8.5.
I used asynchbeans.jar from websphere and now I am bothered that I am writing vendor specific code.
Then I came across commonj work api which is described in oracle java documentation. Now I am thinking to use commonj api from fabric3.
My doubt is, is there a better way to accomplish the same task? An EJB way? Or work manager is good for my requirement?
You have some options:
Asynchronous beans. These are vendor-specific, as you mention.
commonj is just barely not vendor-specific. As far as I know, it was only implemented by IBM WebSphere Application Server and BEA WebLogic. The API was effectively superseded by Concurrency Utilities for Java EE, which is really the best choice.
EJB #Asynchronous methods. Requires using EJBs (unwanted complexity for some).
EJB timers. Requires using EJBs, requires serializable data.
JMS. Probably requires using MDBs to receive the message, requires serializable data.
Actually create threads. The EE specs do not recommend this, but as long as you don't attempt to use EE constructs (lookup("java:..."), JPA, UserTransaction, etc.), then you should be fine.
JavaEE7 has the managed executor, that you can try. You can spawn a task with it, and recieve managed callbacks in a handler. This is part of EE standard and should be platform agnostic.
See JDoc here:
http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ManagedExecutorService.html
If you need to be sure that all your log entries are safely written, then you probably should use JMS with persistent messages. Otherwise you could use #Asynchronous EJB methods.
As per my understanding java.net talkes with glibc.
I want to know in Java JDBC source, which method is talking with glibc socket methods for implementing socket in Java.
And where can I get the definition of socketRead0
It isn't in the JDBC source code at all.
It is in the java.net source code, and its native JNI past, and the JVM library that supports it. All over the place. Keep looking.
Why do you think you need to know? You don't.
JDBC is an interface.
The actual code implemented by a JDBC provider. Each provider depending on there background and what was flavor of the month when they first implemented thier JDBC library will probably be using a different method.
Of the two I am most familiar with SQLITE and DB2, the sqlite implementation just calls the sqlite C api. The DB2 implementation makes extensive use of java asynchronous IO libraries as well as the standard JAVA sockets libraries.
I'm looking into a NoSQL database for use with Vert.x
Based on the not so favorable results mongoDB is out, so I'm looking at CouchDB/CouchBase, not at least since some of our data collection runs on RaberryPI fed by Arduino I/O (with a Rasbery PI CouchDB instance for offline collection).
What Java library would be suitable/best for use with CouchDB and Vert.x
I don't know a lot about vert.x but it appears to run on the JVM, so you should just be able to use Ektorp, which is pretty much the standard Java library for CouchDB nowadays. It covers all the core functionality, it's fairly well thought out, and the maintainer has been reasonably responsive to pull requests etc, as far as I've seen.
There's more documentation on Ektorp here.
I am not allowed to compile the java class into the instance of Oracle we're running on, per architects request, so I am looking for alternatives. The requirement is to utilize a java library located on an application server on the network. Is it possible to call a java method located on another machine from PL/SQL? I found this article talking about external procedures in Oracle, but I'm not sure that it allows for this. As a side not, the performance would also have to be fast enough to be used in batch processing of thousands or millions of calls.
I suspect the best you can do is add entries to another table which your Java process polls to get each or batches of messages. Oracle is not really designed for message processing.
In any case, I would discuss this with your Architect what to do as he is the expert. ;)
If your Oracle system can't do the job, you may need to have a solution which doesn't use Oracle.
You have three options:
1.) We solved a similar problem by making PL/SQL call HTTP using UTL_HTTP and then let the app-server call the java procedure. We did this to interface our Oracle Database with Oracle Reports. The PL/SQL fired an HTTP Request which was received by the app-server which called Java. The Java can call back PL/SQL via normal JDBC.
2.) You might not be able to load that java proc, but maybe you can create some other java stored procedure that can invoke it using RMI.
3.) AQ is another method. Basically you can Queue a message using AQ and use JMS on the App Server to Dequeue it and use it.
Option 3 would be the fastest, though we have tried option 1 and the latency for this is not as much as you might it. It also offers a way to do some parallel processing by running multiple requests in parallel.
I am interested in creating a module which accepts TCP connections and handles OCI calls made from db tools like Toad, or PL/SQL Developer.
My aim is to manipulate data before sending it to client, hide some stuff etc. Is it possible to do something like that ?
More specifically, we created a data migration tool coded in java. If i can get calls from a db tool and call the tool's methods using JNI, i achive what i am intended to do. As far as i know there is no api to create a OCI server to connect.
First decide if you are binding to oci or jdbc. The solutions are very different depending on the technology.
Second, keep in mind that while you simply "connect" to a socket, the oci or jdbc protocol is going to request data according to it's protocol. In other words, it is not enough to quickly create an OCI server, you need to have code to actually respond to the requests.
The simplest way of doing that is to actually use a database, but one with a different configuration. The only other way to do that is to write something that simulates a database. With enough simulation, you actually find that you are moving closer to implementing a database.
Perhaps it would be much easier to find a small, compact database like HSQLDB to actually provide a database for your testing via TOAD; however, it will be a different database (which may introduce other issues) it won't support oci (only Oracle supports the Oracle Call Interface) and odds are you will eventually have to test against a live Oracle database anyway.
You can use the Oracle Express edition for testing purposes: http://www.oracle.com/technetwork/products/express-edition/downloads/index.html