Oracle Java blob graphics retrieval Oracle Database Tips by Donald Burleson

Creating a Simple Application Using Oracle, BLOBs and JAVA

Also see how to insert a BLOB image from a client PC .

For immediate expert assistance in Java graphics for images in Oracle, just call us or e-mail  .

This simple application  will provide a list of graphics stored in the database to the user on request, allow the user to enter an index value which is then used to query the database and pull up the requested graphic for display.

From the description we can see that this application is actually a combination of two applets, a canned query return and a BLOB retrieval display. This application combines the two into a single applet and adds the capability to specify the graphic returned. Listing 9 shows the complete application.

Listing 9: Full Code for Graphics Retrieval Applet

To give you an idea what the different sections do, look at Figure 5. Figure 5 shows the Blob Retrieval application as it looks when it is first started. Notice we have five main panels, these being the two top button panels, the central query and BLOB display panels and the bottom status display panel. All of these panels are attached to a main frame component.

Figure 6 shows the results of a mouse click of the ìGet BLOBsî button. The click of the button institutes a query of the internal_graphics table showing the index value, description and type of each BLOB currently stored in the database. Notice how the awt panel component automatically adds scroll bars to text regions as needed. Also look up in the ìEnter BLOB ID:î text box, we have entered a BLOB Id from the display on the right but have not clicked on the ëShowî button, yet.

Figure 7 shows the results from clicking on the ìShowî button. Clicking on the ìShowî button initiates the query to get the BLOB locator from the database, use the BLOB locator to retrieve the actual image data from the database using the DBMS_LOB package and place the result in one of a rotating pool of temporary files. Finally, the image is displayed on the graphic canvas, a part of the right panel.

So, how is all of this accomplished? We first initialize the classes we need iin the start of the applet, then in the init() method we set global variables and components. A look at the global variables shows we are initializing a new class called MediaTracker, but more about this in a minute. We are also initializing buttons and panels. Another new item I mentioned in the description of the applets actions is the Canvas, a canvas is used to draw on from within an applet or application. A canvas is usually attached to another object, or container if you prefer, such as panels, frames, windows or even buttons. Lets look at the globals:

Notice the use of the media tracker with the theTracker = new MediaTracker(this); line of code. This line attaches the media listener to the imageFrame components blobPanel. The blobPanel contains the blobCanvas drawing component. Another method we have used before but not commented on is the pack() method. The pack() method makes a component just big enough to hold its components. The pack() method can cause problems with graphic elements if the graphic element isnít initialized, this is especially true of the Canvas class of objects, more on this later.

The next section of code determines what actions are taken when the buttons are clicked using the mouse buttons.

Rather than use a more modular approach (which by the way I tried but it ended up more complex than I liked) I decided to integrate the operations into the actionPerformed(ActionEvent event) module.

In this case if the execute_button (Get BLOBs) is clicked, the code to retrieve the contents of the internal_graphics table is activated. Notice that at the end of the process of retrieving the BLOB data I place the focus of input into the getblobid text area so the user doesnít have to manually select the area using a mouse action.

The next action item is the show_button (Show). If the show_button is clicked, the value from the getblobid region is scraped from the screen using a getText() method call. This getblobid value will be used in a query to get the BLOB of choice. First, we reconnect (if needed) to the database and get the next sequence value from a database maintained sequence called image_seq. This sequence is set to forever cycle between 1 and 32 and allows us to randomly associate our graphic with one of the 32 temporary image files.

I found that if I attempted to use a single temporary image file the graphic context would not remap (would not display). I assume that since JAVA saw I was using the same file name it meant I wanted the same graphic. This behavior even persisted if I used a dispose() method and a System.gc() call (the dispose is supposed to destroy the graphic context and the System call gc() initiates a garbage cleanup). Use of multiple temp files corrected this rather annoying feature of JAVA. Once we have the temporary file we can proceed to SELECT the BLOB id from the internal_graphics table and pass this information to the dumpBlob() method. Also notice that you must create a new instance of tracker at the start of the run or any error returned is carried into the next cycle of operation adfinitum.

Once control returns from the dumpBlob() method the image is retrieved from the temporary file and the MediaTracker object is attached to the process retrieving the image from the file. The MediaTracker object follows the progress of the image load into memory and if there is a problem, reports it back to the process. The MediaTracker is useful in situations where images are being transferred from one net location to another to prevent draw and paint routines from attempting to draw incomplete graphics. Once a graphics context is assigned, the control is returned immediately, without the call to the MediaTracker the image might not be complete before operations using it begin.

The next set of commands kept me up several nights figuring out. When I first wrote the application I could get the graphics to display only by collapsing and reinitializing the window using the frame interface with mouse clicks, hardly what I was wanting.

The act of making the blobPanel invisible, then doing the call to  repaint() and making the panel visible fixed the problem. As a final step in the process I return focus to the getblobid text area, again for user convenience. Once a graphic context is initialized, it will remain in memory cluttering things up until a dispose() is issued against it. Using appletviewer in a MS-DOS window on the NT4.0 I was only able to display about 2-3 images before the process locked and required a destructive drop using the task manager. With addition of the dispose method call in the overridden destroy() method call this increased to 12-13 and with a final call to garbage collection (System.gc())  I was finally able to alternatively retrieve and display an unlimited number of images.

In this applet the paint() routine is encapsulated in an overridden Canvas class definition. The paint() routine has been expanded to include call to the getPreferredSize() overridden method to get an initialization set of dimensions set by globally declaring the iWidth  and iHeight integer values and using these as a return value set whenever the getPreferredSize() routine is called. By tying the values returned to iWidth  and iHeight whenwe reset these to the actual and adjusted width and height of the graphic any calls to getPreferredSize() returns the proper value. Notice we use a new class, the Dimension class, to set up our iWidth and iHeight values into the minSize() calls. Notice how we use the value of theTracker (the MediaTracker object) to verify if the image is properly loaded.

The dumpBlob() method uses the JDBC Oracle implementation to prepare and execute the calls to the database. The following code snippet shows the Oracle specific calls:

The question marks in the calls to prepareCall() method mark locations where variables are written. These variables are written using code similar to the following code lines:

The first call to the registerOutParameter for cstmt1 registers the first question mark in the line: ("begin - := dbms_lob.getLength (?); end;"); as a value that is returned (dbms_lob.getlength() is a function and must return a value) and sets its type as NUMERIC. The call to setBlob() registers the second (as shown by the 2) question mark as an input to the function in cstmt1, setting it to the actual BLOB identifier. The last statement in the snippet executes the statement cstmt1 after making the substitutions. This call to dbms_lob.getlength() returns the length of the BLOB. This length must be known before we can retrieve the BLOB using dbms_lob.read() as over runs of the BLOB bounderies are not permitted and will result in an error if they happen.

The next section in dumpBlob() uses repeated calls to the dbms_lob.read() Oracle8 procedure to read the BLOB values piecewise. Once the pieces are placed in memory using the getBytes() method, calls to the write() method of the JAVA File class place the bytes into the designated file. To create a file rather than use an existing temporary file,  more advanced streaming methods as demonstrated in "Graphic JAVA 1.1 - Mastering the AWT, 2nd Edition", David M. Geary, The SunSoft Press, 1997, should be used.

 One technique to take note of in this code snippet is the calculation:

if ((i + read_this_time)>length) chunk = (int) (length-i);

This calculation prevents the loop from reading past the end of the BLOB and generating an exception which would cause the transaction to be backed out resulting in only a partial (if any) image transferred into our file.

Once the image file is created and the BLOB has been completely transferred, the file and the Oracle statements are closed: