OrindaBlog

Creating Oracle PL/SQL Web Services With OrindaBuild

noreply@blogger.com (David Rolfe) — Mon, 22 Feb 2010 17:31:00 +0000

We have a new white paper on "Cost Effective PL/SQL Web Services With OrindaBuild". The key points are below...

Regardless on whether you use our technology or not there are some things to bear in mind when moving your existing Oracle database to SOA:

Creating database web services is non-trivial.

The ‘glue code’ that sits between your database and your web service engine will represent the bulk of your web service conversation effort. Not only that, it will need to be maintained as long as the underlying database exists. Creating this code may require more work than it took to create the database it uses.

Simply sticking a Java Data Access Object layer on top of Oracle won’t give you the basis for web services.

Most existing systems will have business logic that is expressed with SQL statements. In such cases having access to the database schema is not enough - outside knowledge on how the data should be interpreted is required to turn the raw data stored in potentially hundreds of tables into valid business information.

Most existing systems will use PL/SQL, which is not always Java-friendly.

PL/SQL offers huge advantages to developers, provided they can access it easily:

It allows a database designer to create PL/SQL packages that provide the functionality the application needs without exposing the users to the underlying complexity of the database.
The DBA can optimize the SQL statements that interact with the database without changing any external source code.
It’s significantly faster than raw SQL as it allows multiple requests to be met in one interaction, such as returning a customer as well as their purchase data while simultaneously logging the request for audit purposes.

But:

PL/SQL makes extensive use of records and arrays as parameters.
PL/SQL procedure s that take records or arrays as parameters can be hard to access usingJDBC.

Many PL/SQL procedures were never designed with JDBC in mind, and as a result the code to call the procedure can be many times longer than the procedure itself. The code can also be very, very complicated and beyond the ability of some developers to create within an economic timeframe.

As a result of this when writing Web Services manually many developers end up either reverse engineering PL/SQL into Java or writing wrapper procedures that load and unload records into scalar variables instead.

How does OrindaBuild Help?

OrindaBuild solves this problem by writing the missing Java code for you. It’s GUI based, is easy to use and almost totally automatic. It’s also integrated with Eclipse, the industry leading IDE. You can even use OrindaBuild to package and deploy solutions in one step without writing a single line of code by hand.

If you buy OrindaBuild you will be able to generate Web Service compatible Java for the vast majority of your existing Oracle databases using a simple GUI with minimal work.

Fully functional but time-limited versions of OrindaBuild are freely
downloadable, so you can do your own evaluation.

You can also download OrindaBuild as an Oracle SQLDeveloper Extension or an Eclipse Plugin

OrindaBuild PL/SQL Web Service Generator Now Available For Eclipse 3.5

noreply@blogger.com (David Rolfe) — Fri, 19 Feb 2010 15:58:00 +0000

OrindaBuild, a Web Service Generator for Oracle PL/SQL and SQL, is now available as a plugin for Eclipse 3.5.

To get a demo version do the following:

Click on "Help", then "Install New Software"...

Then add "http://www.orindasoft.com/public/ec35" as a new update site...

Now you've got the Orinda Site added you can go ahead and get a demo copy of the OrindaBuild plugin for Eclipse:

OrindaBuild writes the Java you need to call your PL/SQL procedures and SQL statements. Version 6 is now Production.

noreply@blogger.com (David Rolfe) — Fri, 28 Aug 2009 16:06:00 +0000

OrindaBuild 6 automatically writes the JDBC calls and other Java code to call Oracle PL/SQL Stored Procedures from Java without having to use SQLJ or JPublisher. OrindaBuild can be pointed at your Oracle database and will write thousands of lines of access code in minutes. The end result is a Java service that exposes your existing Database's PL/SQL procedures along with any SQL statements others need access to.

New Functionality supports all PL/SQL array types.

Previous versions of OrindaBuild only supported one of the four different kinds of arrays in PL/SQL. We now support all of them, including arrays that can not be represented directly in JDBC.

No other product can write Java JDBC calls for the PL/SQL OrindaBuild can.

Unlike JPublisher, OrindaBuild works with almost all possible PL/SQL procedures. OrindaBuild has no external dependencies other than JDBC drivers and does not require the use of SQLJ.

Try generating Java to run your PL/SQL and SQL

A fully functional time limited demo version of OrindaBuild is available for download. In addition to a stand alone version it's available as extensions for SQL Developer, Oracle JDeveloper and Eclipse.

For further information see here.

OrindaBuild 6 Beta: Run any and all PL/SQL or SQL as a Java service without writing code yourself

noreply@blogger.com (David Rolfe) — Tue, 10 Feb 2009 22:28:00 +0000

The Need

Utilities that automate the creation of Data Access Objects for Oracle and Java have been around for years, but suffered from a fundamental limitation - anyone who has worked with real-world Oracle databases for any length of time can tell you that simply being able to access the tables isn't good enough, and that much of the functionality of an Oracle database will be implemented in PL/SQL procedures and complicated SQL statements.

Access to the raw data itself is at most 80% of the picture, and implementing the other 20% using a DAO paradigm involves re-implementing the same logic that lives in PL/SQL and complex SQL statements. So if you work with Java and you want to access an existing Oracle application you can really benefit from a utility that automates the task of writing all the Java JDBC calls you would otherwise need to write.

To make things more complicated, there's a fundamental disconnect between the parameters you can pass to a PL/SQL procedure and those supported by Oracle's implementation of JDBC. Real-world PL/SQL makes extensive use of different kinds of records and arrays as parameters and return values for PL/SQL procedures and functions, but you can't directly use JDBC in every case because Oracle's JDBC implementation only recognize one kind of record and array.

So while you can pass arrays of oracle Type objects to java via JDBC you can't pass arrays of records that are defined inside a PL/SQL package.

This creates a problem for our Java developer, as they now have to either write a new PL/SQL API on top of the existing one or re-implement the logic expressed in the PL/SQL with individual SQL statements.

What we used to do

The earlier versions of OrindaBuild worked within this limitation. We failed to understand how serious a limitation this was and assumed that because JDBC couldn't do it we couldn't do it either and therefore everyone had to live with this restriction. What we didn't initially realize was that the majority of the world's enterprise grade PL/SQL uses arrays or records that aren't supported by JDBC.

No more limitations - pass any kind of array you want to PL/SQL from Java

Over time it became clearer and clearer that we needed to address this issue. OrindaBuild 6, which went into Beta today, now supports access to all possible arrays and records used by PL/SQL from Java, without you having to modify the PL/SQL.

For example: OrindaBuild can write the Java classes Java< needed to call these PL/SQL Procedures. Follow the links to see the generated Java classes:

 PACKAGE PACKAGE_ARRAY_EXAMPLE AS

/*

 * THIS EXAMPLE SHOWS HOW TO CALL PL/SQL PROCEDURE

 * THAT TAKES A PARAMETER DEFINED IN A PL/SQL PACKAGE

 * AS AN ARRAY OF %ROWTYPE (TABLE RECORD).

 * THERE IS NO DIRECT WAY TO CALL THIS PL/SQL PROCEDURE FROM JAVA.

 * INSTEAD WE USE ORINDABUILD TO CREATE JAVA JDBC CODE THAT

 * CAN BYPASS THIS LIMITATION AND RETURN OR ACCEPT A PL/SQL

 * ARRAY FROM JAVA USING JDBC.

*/

--

 TYPE FLIGHTS_PLSQL_ARRAY IS TABLE OF FLIGHTS%ROWTYPE;

--

 TYPE BOOKINGS_PLSQL_ARRAY IS VARRAY(30) OF BOOKINGS%ROWTYPE;

--

 PROCEDURE GET_PLSQL_ARRAY_OF_FLIGHTS

      (P_CITY         IN            FLIGHTS.DEPARTURE_CITY%TYPE

      ,P_FLIGHTS_FROM    OUT NOCOPY FLIGHTS_PLSQL_ARRAY);

--

 PROCEDURE ADD_BOOKINGS_PLSQL_ARRAY

     (P_CUSTOMER      IN      CUSTOMERS%ROWTYPE

     ,P_BOOKING_TABLE IN      BOOKINGS_PLSQL_ARRAY

     ,P_STATUS_MESSAGE    OUT NOCOPY VARCHAR2);

--

 END PACKAGE_ARRAY_EXAMPLE;

No other product has this capability.

For an example of a generated Java service that uses Java to call PL/SQL procedures that take PL/SQL Package Arrays as parameters see here.

Getting OrindaBuild

OrindaBuild demo versions expire after roughly a month. We do the following kinds of Demos:

Full windows install - OrindaBuild as a full stand alone Java Swing GUI.

Oracle SQL Developer Extension - Works for SQL Developer 1.5.5440 and higher.

Eclipse Plugin - Works for versions 3.3 and 3.4

Licencing

OrindaBuild is not free software. We have no problem with you downloading it as often as you want but we expect you to buy a license if you use it in a commercial environment. Note that OrindaBuild does not have a run time engine - it has a run time library, but license holders get the source and thus end up with a 100% source code solution. In practice you only need 1 copy of OrindaBuild per project.

OrindaBuild Web Service Plugin for Oracle SQL Developer - 10,363 users and counting

noreply@blogger.com (David Rolfe) — Tue, 13 Jan 2009 17:09:00 +0000

Over the past two years we've put considerable effort in writing and in several cases re-writing OrindaBuild extensions for tools such as Oracle's SQL Developer, JDeveloper and Eclipse 3.3.

We launched our JDBC code generator for Oracle SQL Developer 1.5 in July 2008. It's been a great success - as of today we've had 15,699 downloads from 10,363 different IP addresses. To add it to your copy of SQL Developer start the "Check For Updates" wizard and then choose "Third Party SQL Developer Extensions".

Once installed you'll find that an "OrindaBuild" files folder is added to the folders that appear under each connection. When you double click on the file you open OrindaBuild for the parent connection and can create Java to run your PL/SQL procedures, access tables or call any SQL statement. For more information see here.

The demo version of the product expires after 6 weeks, but we allow repeated demo installs provided you don't use the product commercially.

Currently the product doesn't handle write Java to call PL/SQL procedures that take ARRAY or VARRAY objects defined inside PL/SQL packages. We have just finished implementing this and will release a Beta within a week or so. This means that OrindaBuild will soon be able to write Java to call pretty much any PL/SQL that lives inside your Oracle database, even if it can't be directly represented using JDBC.

Using "Commit Write Batch Nowait" from within JDBC

noreply@blogger.com (David Rolfe) — Mon, 30 Jun 2008 21:31:00 +0000

Anyone who has used the new asynchronous commit feature of Oracle 10.2 will be aware that it's very useful for transaction processing systems that would traditionally be bound by log_file_sync wait events.

COMMIT WRITE BATCH NOWAIT is faster because it doesn't wait for a message assuring it that the transaction is safely in the redo log - instead it assumes it will make it. This nearly eliminates log_file_sync events. It also arguably undermines the whole purpose of commit, but there are many situations where the loss of a particular transaction (say to delete a completed session) is perfectly survivable and far more preferable than being unable to serve incoming requests because all your connections are busy with log_file_sync wait events.

The problem anyone using Oracle's JDBC driver is that neither the 10.2 or 11.1 drivers have any extensions which allow you to access this functionality easily - while Oracle have lots of vendor specific extensions for all sorts of things support for async commit is missing.

This means you can:

Turn on async commit at the instance level by messing with the COMMIT_WRITE init.ora parameter. There's a really good chance this will get you fired, as throughout the entire system COMMIT will be asynchronous. While we think this is insane for production systems there are times where setting it on a development box makes sense, as if you are 80% log file sync bound setting COMMIT_WRITE to COMMIT WRITE BATCH NOWAIT will allow you to see what problems you face if you can somehow fix your current ones.

Change COMMIT_WRITE at the session level. This isn't as dangerous as doing it system wide but it's hard to see it being viable for a real world system with transactions people care about.

Prepare and use a PL/SQL block that goes "BEGIN COMMIT WRITE BATCH NOWAIT; END". This is safer than the first two ideas but still involves a network round trip.

Wrap your statement in an anonymous block with an asynchronous commit. This is the best approach we've seen. Your code will look something like this:

BEGIN

--

insert into generic_table

(a_col, another_col, yet_another_col)

values

(?,?,?);

--

COMMIT WRITE BATCH NOWAIT;

--

END;

Oracle 11G first look

noreply@blogger.com (David Rolfe) — Wed, 15 Aug 2007 07:23:00 +0000

Oracle 11g is now available for download, but only for Linux. This blog posting covers practical issues we've seen since we started playing with it. If you are looking for marketing/new feature info you can find the PDF's here.

Installation

Download is a 1.8GB zip file.
The Installer requires a minimum of 922MB of memory and large quantities of swap space. If you need more swap you can use 'swapadd'.
Installer for X86 expects recent patches - don't think that your copy of RHEL4 will work without new rpm's.
Oracle has changed the default location of the *dump and other configuration directories.
Some minor Kernel tweaks required.

DB Upgrade Process

Process expects that your copy of 10.2.0 is patched to 10.2.0.3.0 to address a DST issue. If not you have to manually apply Oracle patches and jump through various other hoops. We encountered problems with the upgrade and eventually built an11g DB from scratch for our regression testing. This may a fundamental problem with the upgrade but is more likely to be because 'someone' unplugged our router during the upgrade process and left the DB in a mess.

Security

Passwords are now case sensitive. This will cause hours of fun.

11g JDBC Driver

1.4 and earlier versions of Java are not supported.
9.0.1 and prior versions of Oracle are not supported.
'oracle.jdbc.driver' is gone - but then it's been deprecated since 9i...
We were expecting OracleConnection to be extended to prrovide support for Asynchronous Commit, but that didn't happen. We'll be adding our own support to OrindaBuild.

JPublisher

The 11g version of JPublisher still creates .sqlj files but then deletes them after producing .java files. JPublisher still has all its other limitations.

OrindaBuild 11g Support

We have completed regression testing and the first build that supports 11g is available here. JDeveloper users can use this update center:

http://www.orindasoft.com/public/jdev103Center.xml

SQLDeveloper users can use this update center:

http://www.orindasoft.com/public/sqldevCenter.xml

Oracle's DECODE funtion...

noreply@blogger.com (David Rolfe) — Thu, 12 Jul 2007 06:11:00 +0000

Oracle's decode function can be used to create arbitrary ORDER BY clauses. This is useful if you are providing lists with the most frequently picked value at the top - e.g. a list of countries which starts with 'United States' and then turns into a conventional alphabetical listing. Your SELECT statement will have two things in the ORDER BY clause - first it sorts by a DECODE that turns your favoured value into '1' and all other values into '2' and then it sorts the rest of the list conventionally. The alternatives to using DECODE are to hard code the entire list (bad!) or add a numeric column to the underlying table that defines the sort order, which is a lot more work than a DECODE in an ORDER BY.


SQL> r


1  select country_name


2  from iso_countries


3* order by decode(country_name,'UNITED STATES',1,2)

  , country_name


COUNTRY_NAME


--------------------------------------------------


UNITED STATES


AFGHANISTAN


ALBANIA


ALGERIA


AMERICAN SAMOA


ANDORRA


ANGOLA


ANGUILLA


ANTARCTICA


ANTIGUA AND BARBUDA


ARGENTINA

...

This behavior is common for web sites where drop down lists have to be dynamic (the contents may change) but also require location or market specific default preferences.

While we're on the subject of lists of countries one really should think twice before including Bouvet Island one's list...

BLOBs, CLOBs and BFILEs

noreply@blogger.com (David Rolfe) — Wed, 11 Jul 2007 21:27:00 +0000

Summary

Oracle users currently have 3 different Large OBject data types to choose from - BLOB, CLOB and BFILE. We'll look at the basic mechanics of how they work from a Java developers perspective and then explain why oracle.sql.BFILE poses serious challanges for web service developers.

LOB's 101

When you retrieve an oracle.sql.BLOB or oracle.sql.CLOB the single most important thing to understand is that you're dealing with a pointer, not a file. Not only that, but that the oracle.sql.CLOB you just retrieved from the database is totally independent of the SQL statement or PL/SQL procedure that was used to return it to you. What you've actually got is a pointer to a large object inside the database that will continue to exist until your commit, rollback or lose your connection. Once you understand this life will become bearable. There are significant API changes for Oracle's JDBC drivers as you move up through the different versions of Oracle. You will need to re-read the JavaDocs and check your LOB code line by line when you upgrade. Of course, if you used OrindaBuild you could just re-generate your code...

BFILE

oracle.sql.BFILE is different. A BFILE is a pointer to a file that resides outside the database. In fact a BFILE consists of two things:

The name of an Oracle DIRECTORY (as found in the ALL_DIRECTORIES view)
The name of the file within that directory

oracle.sql.BFILE objects are small - often under 100 bytes. Oracle makes no attempt to verify that the file referred to by the oracle.sql.BFILE exists and is usable until you attempt to read from it. The only way to create an oracle.sql.BFILE is to call use the SQL function BFILENAME, which implies a database call. You can quite happily create BFILE objects for files which don't exist. This makes sense when you consider how much work checking every BFILE every time it was referred to would impose on the server, but obviously needs to be understood by the developer.

LOBs and Web Services

If you're going to write a Web Service app and are one of the surprising number of people who are still on 8i you should upgrade to at least 9i. Creating CLOBS and BLOBS is a lot easier because of the createTemporary() method that appears in 9.0.1.Using LOBS in a Web Service environment is not a problem, provided you think carefully about how big the LOBs will actually be and how much memory you'll need - Oracle can support huge CLOBS and BLOBS that simply wouldn't be practical in a Web Service scenario.Creating BFILES and Web Services. If you are writing a web service application that stores LOBs in Oracle you should avoid the use of the BFILE data type. It may well seem very tempting but the JVM which is running the service will need to be on the same filesystem as the Oracle database server, which will severly limit scalability. If, as is normal, your JVM is on a different machine you could in theory get round this by creating a BFILE that points to a non-existent directory/file on the database server and then trying to asynchronously move the file to where the BFILE pointer claims it is before anyone actually tries to read the BFILE. For obvious reasons we don't recommend this.

[This post originally appeared on JRoller]

Not All Jdbc Advice Is Good JDBC Advice...

noreply@blogger.com (David Rolfe) — Sun, 01 Jul 2007 16:51:00 +0000

While wandering around the web I stumbled across a link to a sample chapter for 'Java Programming with Oracle JDBC', published in December 2001 by O'Reilly. Now 2001 is a bit dated but one would assume that if they are plugging it on their web site it must still be relevent. And that any glaring

errors would have been corrected, right? Think again...

The author spends the chapter conducting elaborate benchmarks which in his view demonstrate that there's nothing special about PreparedStatement and that you should really be using Statement most of the time. His reasoning is based on the premise that the additional set up costs of Prepareing a statement and sending all the bind variables etc cause applications to run more slowly than if you had simply said something like:

code>

Statement stmt = conn.createStatement();

stmt.executeUpdate(

"insert into oehr.testxxxperf ( id, code, descr,insert_user, insert_date ) "

"values ( " + Integer.toString( i ) + ", '125678901234567890', "

"'1234567890', " +

"USER, to_date('" + sdf.format(new java.util.Date(System.currentTimeMillis())) + "', 'YYYYMMDDHH24MISS'))");

instead of:

PreparedStatement stmt = conn.prepareStatement(
"insert into oehr.testxxxperf ( id, code, descr,insert_user, 
insert_date ) " +
"values ( ?, ?, ?, ?, ? )");
startTime = System.currentTimeMillis();
int i=1;
stmt.setInt(1,i);
stmt.setString(2,"123456789012345678901234567890");
stmt.setString(3,"123456789019012345678901234567890");
stmt.setString(4,"ZXVI01");
stmt.setDate(5,newjava.sql.Date(System.currentTimeMillis()));
stmt.executeUpdate();



The point made is that unless you plan on issuing hundreds of statements the first method is faster because it has fewer network round trips and therefore less elapsed time. All of which is true - provided there is only 1 copy of the client software being used. In practice what will happen is that using Statement in preference to PreparedStatement will cause the database server to devote significant resources to compiling execution plans for each and every version of the insert statement being called. Indeed, not using PreparedStatement and bind variables is listed as the second most common mistake in Oracle's '
Top Ten Mistakes Found in Oracle Systems'.There's also a less obvious but equally serious problem with cobbling together your SQL statements instead of using bind variables and PreparedStatement  - sooner or later someone with an apostrophe in their name will show up and cause a syntax error:


Int empno = 42;
String empname = "O'Reilly";
String myStatement = "INSERT INTO EMP (empno, ename) VALUES ("
+ empno + ",'" + empname + "');";



But wait... it gets worse! If you're working on a public facing web system and some bright spark realizes you are hacking together SQL statements you could have something like this happen:


Int empno = 42;
String ename = "'Smith', sal = 99999";
String myStatement = "UPDATE EMP set ename = "
+ ename+ " WHERE empno = " + empno');";

which means that your Statement would be:

UPDATE EMP set ename = 'Smith', sal = 99999 WHERE empno = 42;

[This post originally appeared on JRoller]



Rowid Madness
noreply@blogger.com (David Rolfe) — Wed, 20 Jun 2007 16:27:00 +0000
For years the first of my interview questions for Oracle developers has been one in which I ask them to explain why it's a bad idea to use the ROWID of table 'A' as a foreign key to table 'B'. This is not hard for a competant person to answer, as ROWID changes when you import the data into another database which will happen sooner or later. It never occured to me that someone could be crazy enough to actually do this, but someone  has.

[This post originally appeared on JRoller]



Why '43113f...0308' is bad news for Java users...
noreply@blogger.com (David Rolfe) — Wed, 06 Jun 2007 19:03:00 +0000
While going through our web server logs recently we found out that we had our first single word google hit. Unfortunately the word in question is 43113f32554e54494d45110e4350500308,
which we suspect isn't terribly memorable. It's thrown as an error id when the JVM crashes and is referred to in the support section of our web site.
We've now had hundreds of people show up at our web site trying to find out about this. We suspect we may see many more, as the underlying problem appears to affect all applications that use the Java 1.3 or 1.4 JVMs.
If you encounter this you will find the following information useful:
This is Sun bug 4820592.
The bug appears to be limited to x86 based systems.
The bug will appear as a JVM crash after the application has done a fair amount of work.
If you try and use the 'debug' mode of an IDE such as Eclipse the JVM crash will take place at odd and changing locations.
Using interpreted mode ('-Xint') is an effective workaround.
Changing other JVM parameters may postpone the crash but will not prevent it.
To prevent it you can:
Move to Java 1.5
Rewrite your code.
In our case we were able to fix the problem by replacing an ArrayList of String[] with an ArrayList of File, with each File containing 0 or more String. We suspect that the presence of zero length 'String[]'s in the arraylist was the root cause of the problem.
[This post originally appeared on JRoller]