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
Related
So, forgive me if I'm too ambitious and this isn't possible, but I am wondering if it's possible to like set a variable while my program is running, have it closed, have the computer shutdown, and have the app start up again, and have that variable the same as it was.
I've only ever heard of people using servers or files, and so I'm wondering if this is possible.
It is not possible to store a variable forever in side your application. You'll have to either store in the HDD or send a web request to a server where they store values for you.
Build your own website using PHP. There are many free web hosting services. Host your website and your database. Send a HTTP request and you may write a JSON response from your server side.
If that's a lot of trouble, file saving method would be the easiest.
You'll need to write the state of your application out to disk somehow, there's no way around that. Note though this doesn't necessarily have to be a disk on the same machine that your app is running on.
Usually this is accomplished (in the Java land) by using a dB (mysql for instance), then using either plain JDBC to fire off SQL queries, or using an ORM such as hibernate (which will then use SQL underneath.)
You can use something called object serialisation to save the state of your objects to disk directly, and then recall them later. However, this is generally considered an ill advised, obsolete approach (and Oracle are planning to remove it entirely in a future version of Java, so definitely one to stay away from.)
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 developing a web application with php that needs to synchronize a local mysql database that a java desktop version of the web application is interacting with. At the same time i also need the local db to synchronize with the remote db. How do i do this without using other software like MySQL Compare. I will really appreciate the help. Thanx guys.
You clearly have a significant architecture issue. It needs to be planned very well. Two-way replication clearly isn't going to work unless you have thought it out very carefully and understand how to do conflict resolution and what impact that will have on your application. In particular, you can forget using AUTO_INCREMENT.
For one-way replication, you can use mk-table-sync, or use mysql replication in some way (there are a variety of possiblities).
You can also run another mysql instance on the server, use mk-table-sync to periodically synchronise it locally, and use mysql replication on that. This has some benefits, particularly if there are some tables you don't want to replicate.
You really need to think about how it's going to work, if you plan to do two-way synchronisation. It is possible that you may end up writing custom code to do it, as the conflict resolution mechanism may mandate it.
I'm looking to add a pretty simple SQLite database to an existing Java EE application. I'm very used to using EJBs, ORMs, EntityManager, etc. to work with SQL databases. I've never not used some sort of ORM to work with relational DBs in Java.
I've been "recommended" to use a Java wrapper for SQLite, rather than a JDBC driver - so I'm kind of naked and ORM-less (right?). I'd like to get this up and running quickly.
Context
I've been using an in-memory cache, implemented as a Map, which gets filled with entries linearly over time. At some point, like when the app runs overnight, the cache will use all available heap space. Hence, storing the cache on disk (as a SQLite database) rather than in memory (as a Java Map).
Questions
How should I manage resources like SQLiteConnection? Normally I would let the container worry about all this, but since I'm not using JDBC, I have to do all this !##$%ing, non-value-added stuff manually - right?
Is there a way to implement this cleanly and transparently? I'd like to be able to just swap out an implementing class - e.g. replace FooMapCacheImpl with FooSQLiteCacheImpl.
"[Most] methods are confined to the thread that was used to open the connection". Is there a simple, straightforward way to ensure that I don't try to access a SQLiteConnection from threads other than the one that opened it?
...and the flip side of that question: can I avoid creating a new connection every time I want to read from/write to the database? It seems a bona fide PITA to have to manage connections per-thread rather than, say, per instance, which is how I've been thinking about communicating with databases in the past.
Basically
I'm rather lost when it comes to working with databases in Java/Java EE, without using an ORM.
What's the right way to do it?
I don't think It is too hard to make a front end that would implements Map and save everything to a database using JDBC, but before doing it, think twice about it. The performance of the whole system might be affected badly.
However, if the root cause of your problem is the lack of Heap space, you should take a look at Terracotta's BigMemory. However, it is a commercial (non-free) product.
Terracotta has a pretty good cache framework as well (ehcache) which is opensource. Look at the cookbook, it might be inspiring.
If you want to do everything by hand, and you don't mind using Spring, try spring-jdbc. It is very easy to integrate with any JDBC driver. Take a look at SimpleJdbcTemplate. It does all the boiler plate code for you. You should probably use a connection pool as well, such as commons-dbcp
The easiest SQLite JDBC driver to use is this one. Since it doesn't rely on JNI. It might not be as fast, but for quick testing it is perfect.
If you aren't binded to SQLite, you can take a look at other available JDBC solutions such as hsqldb or derby
I hope this will help you out.
You may also want to look at Berkeley DB Java Edition. It allows you to persist and manage Java objects directly in the library, without requiring an ORM (and the associated overhead). It runs on Android, it's an Java library and can manage data sets ranging in size from very small to very large. It was designed with Java application developers in mind and should be both faster and simpler to use than an ORM+RDBMS solution. You can find more out more about it on our web site at Oracle Berkeley DB Java Edition.
Regards,
Dave
The sqlite4java wrapper is basically a JNI wrapper, it is nowhere near what you want.
An ORM like eclipseLink would anyway be a layer on top of JDBC and the Entity manager would always end up using JDBC accesses.
Instead, sqlite4java allows you to call SQLite in java instead of having to do all the JNI wrapping yourself.
If you want to use an ORM and your preferred entity manager then you should use a JDBC driver and the sqlite4java wiki references a few of them.
Hope this helps.
We are trying to connect to a SQL Server instance used by the ACT CRM system. They have managed to lock things down so it isn't possible to connect to the SQL back-end using ODBC (there is some special utility that will add ODBC support that you can install if you purchase the primo version of the software, but that's just crazy).
The recommended method of connecting to theses databases is using an OLEDB connection.
Does anyone have any tricks/ideas/etc... for how to make and use an OLEDB connection from Java?
This doesn't have to be JDBC if that's not possible. All we really need to do is execute a SELECT query that returns two fields and parse those field values out for each row. I have very little experience with OLEDB, so 'use JACOB' might be a good answer, but I'd appreciate some details on what the COM calls would actually have to be.
I know this is old, but could help someone to know how I did it
I described in more detail how to do it Here.
That's not your problem. The problem is the way they have locked down the server. Basically on startup it looks for logins other than ACTUSER and removes them.
You can unlock it pretty easily though, then you will be able to connect in the usual way.
https://serverfault.com/questions/77712/sqlserver-need-to-access-an-act-database-for-data-migration
I've managed to unlock mine but I forget how... I think I started it in single-user mode then did some funny stuff involving decrypting a stored proc in the master database and editing it to remove that "functionality". That in turn involved using SQLTrace to see what commands ACT was sending.
I suggest you ask on Server Fault.
Java can not access OLEDB directly. You need to do this in another language like C++ or C#. Then you can access via JNI or external process. If you does not want write the native part of JNI self then you can use JACOB how you suggest it. But I think an external process take the request seem be simpler.
Or use: http://uda.openlinksw.com/jdbc/mt/jdbc-sqlserver-mt/
They develop all kinds of drivers. I used this company before...
Two ways to solve this issue.
Spawn from java an external proc (c#, c++, etc) that connects to SQLSrv using OLEDB and redirect the stdin, stdout and stderr to your java program.
Create a C# listener on a particular port and have java pass all the requests via a client to that listener.