Question

I am working on a web project that is Spring+Hibernate+MySQL based. I am stuck at a point where I have to store images uploaded by a user into the database. Although I have written some code that works well for now, but I believe that things will mess up when the project would go live.

Here’s my domain class that carries the image bytes:

@Entity
public class Picture implements java.io.Serializable{
    long id;
    byte[] data;
    ... // getters and setters
}

And here’s my controller that saves the file on submit:

public class PictureUploadFormController extends AbstractBaseFormController{
    ...
    protected ModelAndView onSubmit(HttpServletRequest request, HttpServletResponse response, Object command, BindException errors) throws Exception{
         MutlipartFile file; 
         // getting MultipartFile from the command object
         ...
         // beginning hibernate transaction
         ...
         Picture p=new Picture();
         p.setData(file.getBytes());
         pictureDAO.makePersistent(p); // this method simply calls getSession().saveOrUpdate(p)

         // committing hiernate transaction
         ...
    }
    ...
}

Obviously a bad piece of code. Is there anyway I could use InputStream or Blob to save the data, instead of first loading all the bytes from the user into the memory and then pushing them into the database?

I did some research on hibernate’s support for Blob, and found this in Hibernate In Action book:

java.sql.Blob and java.sql.Clob are
the most efficient way to handle large
objects in Java. Unfortunately, an
instance of Blob or Clob is only
useable until the JDBC transaction
completes. So if your persistent class
defines a property of java.sql.Clob or
java.sql.Blob (not a good idea
anyway), you’ll be restricted in how
instances of the class may be used. In
particular, you won’t be able to use
instances of that class as detached
objects. Furthermore, many JDBC
drivers don’t feature working support
for java.sql.Blob and java.sql.Clob.
Therefore, it makes more sense to map
large objects using the binary or text
mapping type, assuming retrieval of
the entire large object into memory
isn’t a performance killer.

Note you
can find up-to-date design patterns
and tips for large object usage on the
Hibernate website, with tricks for
particular platforms.

Now apparently the Blob cannot be used, as it is not a good idea anyway, what else could be used to improve the performance? I couldn’t find any up-to-date design pattern or any useful information on Hibernate website. So any help/recommendations from stackoverflowers will be much appreciated.

Thanks

Answer 1

The revised edition of the book (Java Persistence with Hibernate) says:

Table 5.3 lists Hibernate types for handling binary data and large values. Note that
only binary is supported as the type of an identifier property.

Mapping type   Java type   Standard SQL built-in type
binary         byte[]               VARBINARY
text           java.lang.String     CLOB
clob           java.sql.Clob        CLOB
blob           java.sql.Blob        BLOB
serializable   Any Java class that  VARBINARY
               implements
               java.io.Serializable

If a property in your persistent Java class is of type byte[], Hibernate can map
it to a VARBINARY column with the binary mapping type. (Note that the real SQL type depends on the dialect; for example, in PostgreSQL, the SQL type is BYTEA,
and in Oracle it’s RAW.) If a property in your persistent Java class is of type
java.lang.String, Hibernate can map it to an SQL CLOB column, with the text
mapping type.

Note that in both cases, Hibernate initializes the property value right away,
when the entity instance that holds the property variable is loaded. This is inconvenient
when you have to deal with potentially large values.

One solution is lazy loading through interception of field access, on demand.
However, this approach requires bytecode instrumentation of your persistent
classes for the injection of extra code. We’ll discuss lazy loading through bytecode
instrumentation and interception in chapter 13, section 13.1.6, “Lazy loading
with interception.”

A second solution is a different kind of property in your Java class. JDBC supports
locator objects (LOBs) directly.1 If your Java property is of type
java.sql.Clob or java.sql.Blob, you can map it with the clob or blob mapping
type to get lazy loading of large values without bytecode instrumentation. When
the owner of the property is loaded, the property value is a locator object—effectively,
a pointer to the real value that isn’t yet materialized. Once you access the
property, the value is materialized. This on-demand loading works only as long as
the database transaction is open, so you need to access any property of such a type
when the owning entity instance is in a persistent and transactional state, not in
detached state. Your domain model is now also bound to JDBC, because the
import of the java.sql package is required. Although domain model classes are
executable in isolated unit tests, you can’t access LOB properties without a database
connection.

Hope this helps.