Right now I'm facing some performance issues in a web app because of a situation with Oracle saving images and my webapp getting them.
The database where the image is stored gets it from a Oracle Forms' form, which allows user to save some data along the image (as a BLOB). No matter the format you choose as input, it gets saved in a table with its description and stuff, with the corresponding field getting the image is a BLOB.
Now going to the webapp, it reaches the table through a web service querying a stored procedure and a Java WS client, so my webapp gets the image and saves it in the webapp's server's temp folder while needed. The output does not get any particular extension because the DB doesn't tell which extension should it be. Anyhow, the broswer can tell using the metadata. A brief schema of the process goes as follows
Presentation layer <--- Business logic <--- WS Client ---o)--- WS <--- Stored Proc <--- BLOB column
My problem is: how can I avoid the DB serving a bitmap? The performance is awful in specific situations and poor connections because of loading a 1.5MB bitmap. And this webapp must be able to work properly in 256Mb connections. What can be done, then?
Thanks for your help.
Edit: The thing can be treated using BFILE datatype. Thanks for your help. (2010/10/20)
Edit2: The images are uploaded to the database thru a client/server system build in oracle forms (6i/10g). The form itself is the one who stores the image as a blob in the table, transforming it into a bitmap, doesn´t matter if the uploaded image is a light jpg (2011/12/07)
Not sure at which layer you actually want to handle things.
If it is the database layer, then I suspect you need to start using ORDSYS.OrdImage datatypes, and you can them make use of the built-in format conversion operations to turn BMP to JPG or whatever.
Also consider is the problem with large bitmaps or with large image files in general.
Related
After going through many similar looking questions I had no way but put my own question here.
I need to display an image on swing application. The source of image is bitmap data which is retrieved from MS SQL server. I have tried the following ways
TRY 1 - I have tried creating an ImageIcon from the bytes retrieved. No results.
TRY 2 - Saved the bytes in a .png file and tried loading Using ImageIO. This works fine on my local machine but fails on test server. Both are windows machines.
TRY3 - On step 2 I tried saving in different formats than .png. It does not work at all.
Please let me know what am I missing?
NOTE : I have tried including jai jars into the Referenced Libraries also.
You should have stored a hint what format the data has in the database. If not, you can only hope that ImageIO can handle it.
There is no need to write the data to files (which is a pitfall in itself, where would you write them? Think of restricted process privileges and disk quotas). Just create an InputStream that accesses the data directly (e.g. java.io.ByteArrayInputStream), that way you can have ImageIO load directly using the stream based methods.
I have this requirement for my business. We have a swing desktop application that works with a mysql database. At the end of each day the swing app exports the data that has changed and uploads it to a server. The set up is, a user working in an office, will have many companies that he is working with. If he changes any data for that company, then I export that company's data alone from the database. The data is exported in the form of java objects, serialised and stored into a file which gets uploaded.
The next day, if there are any changes made to that company again then I will replace the file in the server with the latest uploaded file.
Now on my server, I would like to work with this file. I would like to convert each of these files into mini databases that a webapp can read. It will not write to it. Everytime the user uploads, the database will be deleted and recreated.
So ultimately each of these files are a small subset of the data that a user has in his desktop application.
Now this issues are:
The objects that I have exported are "Apache Torque" objects. Torque is an ORM tool, basically the object represents the table. I need to convert this object into a database. Sqlite, HSQLDB, Derby...? The database should be small. If the object file is about 5KB, then the database that represents that file shouldnt be 3MB. Derby did that actually.
The java object classes could change. Since the underlying database could change. Hence I will need to deserialise these objects and create a database from it as soon as it is uploaded. Otherwise, I will not be able to deserialise these objects later on. Small changes to the database is fine for the web application. But if I dont deserialise it immediately, then I am stuck.
The conversion from the java object to the database should be fast. Since the user actually waits when his data is getting uploaded I would like to add a maximum of 5-10s additional for the conversion.
Is it ok to have thousands of these mini databases lying around? Is this design okay? Is there an alternate solution?
I wouldn't try to put each dataset into its own database. I would put all of them in one big database, along with a column in the key tables indicating the dataset that each row applies to (this sounds like it should just be a company identifier). This is a more normalised design than having many small databases.
You will then need to write the webapp so it makes queries for particular datasets, rather than connecting to a particular database.
if you adopt that approach, you can deserialize and store the datasets as soon as they arrive. The storage is simply inserting rows into an existing database, so it should be very fast.
In addition, i expect that one big database will be much easier to manage, maintain, report on, etc, than many small databases.
If you tell us more about the details of your schema, we could discuss how the database could be organised, if that would be useful.
I need to make a data file to hold two empty tables with many fields
I have been successful at making a MySQL 5.5 Table with its DOS style IDE OK.
And MySQL registers with NetBeans very well.
Can I make a script to build this from with in my program
or can this be done directly in Java and get a Java file to read file parameters as its executed to create the data base file name.
I have no idea what direction to take to do this and what's possible.
I'm writing in Java and Delphi and Delphi has no MySQL support.
Has any one done anything similar before and how did they do it
The database is to hold 70 meduim size pictures, How slow will updates be when accessing pictures and should I use JPEG or BMP storage for wireless Java apps?
Can Java manage JPEG files and display them?
Lots of questions in one post. Let me try to address each point individually.
Yes, you can write Java code to create your MySQL database for you. On the other hand, tools such Liquibase can do this for you—you just need to learn its XML configuration syntax.
Lots of people have successfully written Java and Delphi code to access MySQL databases. If I recall correctly, at the very least Delphi supports MySQL access through ODBC, if not, through 3rd-party custom components.
Java can store & retrieve JPEG images to/from a database just like any other language, though, in practice, I wouldn't do it that way. Rather, I'd store the images themselves in the file system and just store their locations in the database. RDBMSes weren't really built with handling large binary BLOBs in mind.
How would you like to display the images? If on screen via a desktop client, then, yes, Java's Swing components can easily and readily display JPEG, even GIF & PNG images. If via a Web browser or remote client, then it's really just a matter of serving the images over HTTP to the browser/client app.
I want to store images related to a particular row in my table,
So my table is called spot,
and each spot can have multiple images,
should i just store the images in a folder on the server and then store a location to that folder in a column of that row called imagesLocation?
or should there be other information encorporated?
any ideas?
You are on the right track - store the images on the file system (preferably where they can be seen by the web server), and store just a path to them in the database. This can greatly reduce I/O to your database server. Often you will just create a <img> tag with the path, so you can lead the loading/caching of these files to your webserver - which it is really good at.
Yes, you should store the file in the file system and the location of the file in the database. In my experience the database connectors perform very poorly on large pieces of binary data in the database.
You should store all the meta-information you need in the database so you don't need to rely on the OS for anything else than storing the raw bytes.
One possible way of storing images in a database is as a stream of bits. This works as a storage mechanism, but I can't figure out how to embed this data into a webpage as an image once I extract it to fulfill a client request.
I'm working with Servlets in Java. Can anyone give me some guidance?
You probably want to write a servlet that reads the BLOB from the database and copies directly into HttpServletRequest.getOutputStream(), remembering to set the content type to the appropriate format (image/png for example).
The database id or key or whatever can be encoded in the path (/image/foo), or passed as a query parameter (/image?id=foo). This path is what you use in your <img> tag.
This is probably best written in actual Java, rather than JSP or similar presentation technologies.
Let me share what I am doing with image files and dynamic HTML generation and why - I believe this is a non-standard approach, feel free to comment or use such a system if it works for you. :)
I have several parameterized html, style sheets and image files that go into the html jarred up and saved as [clientid].jar file on the server side. The UI is applet based. At a lean time, the applet requests the file (and associated logic) from the servlet, after due authentication. The servlet wraps up the entire jar file as byte array, encapsulates its contents (from predefined directory in the unix FS) and the business logic (from the database) in a FileXfer object and sends it out on an ObjectOutputStream. The applet extracts the bytes and saves the jar as a tmp file in tmpdir, with a deleteOnExit flag.
During execution, when the html is required to be displayed, the applet extracts the necessary files from the archive and saves them in the same directory, filtering the html as required by the business logic. Image files (jpeg, png, etc) are not filtered. All such files are deleteOnExit, so there is no footprint once the application exits. Next it opens the html with a browser tab, and everything I need to display is there in the right format. The applet has the logic of file extraction - e.g., do not extract "logo.png" if it was extracted 15 seconds back to display another piece of HTML, etc.
The advantages I see are:
I get an automatic compression of the bytes I need to transfer from the server to the client, speeding up the transfer by about 3x, (jar uses zip-compression)
The client (applet) picks up the load of filtering the html, thereby relieving the server of the same job
No blob storage of image files on the DB (I read somewhere that blobs are not exactly efficient for DB operations)
The html can be edited independently using standard img tags assuming the image file is in $cwd
[clientid].jar file content is not included in the jar containing the applet class, allowing the applet to load and start up faster.
TIA for your comments, - M.S.