Where I can find information how Oracle performs communication with database on the lowest level, I mean at level of sockets? I want to write a program(without jdbc) that simply perform some statement(select or create). So I need to know what protocol Oracle uses to do this.
Why would you want / need to eliminate JDBC for this? This is exactly why JDBC exists, and why Oracle provides JDBC drivers for their databases. Even if there would exist some low-level protocol documentation for what you're trying to do, you'd have no guarantee of it being portable between Oracle releases, etc.
I'm going to make an assumption in that you're looking to eliminate an install of the Oracle client. If this is the case, make sure you're using the type 4 JDBC driver, or Oracle's "thin" driver - available at http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-112010-090769.html. This does exactly what you're probably trying to do - connecting to the Oracle database through pure Java, without requiring any other installed software - though it technically will still be JDBC.
If you're still insistent on proceeding without any Oracle client components (even including just the Oracle type 4 JDBC driver), here are a few additional links that may be of interest:
Wire-Level Network Protocol Specification for Oracle? Including:
Where can I get Oracle’s Wire-Level Protocol Specification?
Oracle.
Outside of Oracle, only a few wire-level driver vendors have it.
Likewise, unlike the driver vendors, Oracle is the only one with
permission to distribute it. And, before you ask, I’ve never seen the
specification myself. All of my protocol knowledge is based on years
of research and significant trial-and-error.
SibylNet: An Open Source Wire-level Client Library for Oracle
This project is (was) available at http://sourceforge.net/projects/sibylnet/ , but hasn't seen any updates since 2008-10-07, and doesn't have any files or source code available.
You could take a look at Oracle's documentation on the Oracle Call Interface. It is for use with C, not Java, but if you wrapped it in some Java Native Interface stuff you might be able to workout how to call it.
Not saying it would be painless but ... it's a direction to try.
/b
Related
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 am thinking about starting a project that will communicate to multiple DBMS's. Although unavailable directly from C/C++, JDBC remains attractive for the following reasons:
My software shall be portable between Windows/OSX/Linux. Managing ODBC on each of these platforms on multiple architectures seems very cumbersome as far as I've looked.
I was planning on distributing the JDBC libraries with my application. This seems like a better option that trying to distributing each ODBC driver for the multiple environments.
I am far more familiar with JDBC than with ODBC.
It seems as though JDBC may be better supported in some cases.
I've all but convinced myself this is the way to go. However, I don't know if my inexperience with ODBC and JNI are leading me to make naive conclusions.
Please advise.
I wouldn't involve JNI/Java just for the sake of ODBC. On Windows, just use the native ODBC API. On *nix, unixodbc works well. Also, there are 3rd party vendors such as Progress (DataDirect).
The only gotcha I've seen with unixodbc (and it's not really a unixodbc problem) is with mixing Sybase ASE & Sybase IQ. The Sybase provided drivers for the two DBMS are built differently, making them incompatible at runtime for x64 systems (one is built expecting 32-bit types, the other 64-bit types, and unixodbc must be built accordingly to match the driver needed, and you cannot use both at the same time).
I'd also recommend using an abstraction layer, such as odbc++ (sadly, seems to not be actively maintained - and note the latest odbc++ has 64-bit compatibility issues out of the box), or OTL (which is actively being maintained).
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
I am looking for a database which I can use to store data about certain stock over a number of years. There will probably be a few thousand records. I am writing an application in Java and Clojure which will pull out data from this local database when required to display the data.
I was wondering if anyone knew of a good database to work with for this purpose? I only have experience with MySQL running on the server side.
Which database would be easiest to work with in Clojure and Java for local storage?
Thanks,
Adam
JDK 6 and greater comes bundled with Java DB which good enough for your use case.
For this kind of small-scale application it will almost certainly be easiest if you pick one of the many good embedded Java databases.
My personal top choices would probably be:
H2 - probably the best performance pure Java database overall, and if you believe their benchmarks then it is considerably faster than MySQL and indeed most other databases when run in a single machine environment.
Apache Derby - good all rounder, mature and well supported (Oracle have included a version branded as Java DB in recent JDKs)
After that, you should be able to use them pretty easily using the standard JDBC toolset, so not much different from MySQL.
If you're after a really nice DSL for interfacing with SQL databases with Clojure, you should definitely also take a look at Korma.
I have used Apache Derby for a similar application (although written mostly in Java). They have been running it for almost four years now, and performed more than 60,000 transactions with it with no major problems. Only the occasional bug on my part.
Derby is the same database as JavaDB, however with Derby its easier to keep up on the releases as you can just include it as a dependency, rather than wait on the whim of when the next JDK rev is coming out.
Also, IIRC, JavaDB is only included with JDK, not the JRE.
Depending on the nature of your data and application and your willingness and/or constraints in working with a new database modality, you might also want to consider one of the document-oriented databases, MongoDB or CouchDB. If your data and application are SQL oriented, use one of the databases suggested.
Ok, so it's almost as easy as pie already. But it really should be as easier than it is.
I think I should be able to connect to another database just by putting a JDBC connection string into TNSNAMES. Every database vendor has a type-4 JDBC driver and there's usually a good, free alternative.
With Oracle being such keen Java fans, and with a JVM built-in to the database I'd have thought a JDBC-based linking technology would have been a no-brainer. It seems a natural extension to have a JDBC connection string in TNSNAMES and everything would "just work" - you could "sql*plus" to anything.
But it doesn't work this way. If you want to connect to another non-Oracle database You have to buy something called Oracle Gateways or mess around with ODBC (through something called Generic Connectivity).
[Originality warning... This is related to a previous question of mine but someone suggested I enter a supplementary comment as a separate question. Who am I to argue?]
The answer is the same as for the following questions:
Why doesn't Oracle provide an efficient way of unloading data into a non-proprietary format (e.g. comma-delimited or XML)
Why do most Oracle non-DB products only work with the Oracle RDBMS? (without having to use Oracle Database Gateways)
You've ever heard of the concept of Vendor lock-in?
I certainly think the question was somewhat rhetorical and to be taken with a large pinch of salt. :-)
In that spirit, a suitably flipant answer might be "because they don't want you to use anyone else's database"?
It's a real question - perhaps slightly jokey but certainly not rhetorical. It is entirely in Oracle's interest to make it really easy to access other people's data. At the moment there's lots of ways to do it but none sufficiently straightforward. There's a JVM in the database and JDBC drivers to every other database - it should "just work" so I can only assume it hasn't been made to "just work" for a reason.
My question is whether anyone knows that reason. Does anyone?
TNS is a bit of a mess, imho. It seems to behave inconsistently between different platforms, in my (admittedly limited) experience.
Far be it for me to defend Oracle, but I've had no problems with the JDBC thin driver. (If you read the oracle jdbc docs, they discourage you from using oci unless you have a very good reason.
Pair it with JNDI (on a j2ee app server), and all your connection management problems are taken care of.