why hibernate forcing serialization in session.get method

I see that hibernate's session.get() and load() methods is accepting only Serializable objects.

As per my understanding of hibernate, it will g开发者_如何学Pythonenerate an SQL statement and send it to DBMS. It will never need to send a java object over network.

Why hibernate is forcing serialization on us?

First of all, the fact that Hibernate uses Serializable in some signature doesn't mean that Hibernate will serialize anything, it just means that parameters are serializable if the need arises.

Then, I couldn't find an absolute reference but I think that the strongest argument is:

• Entities Ids are use as key for caching (first level, second level) and may be send over the wire

Some weaker arguments (or not argument at all):

• The Session itself can be potentially serialized (e.g. to be stored in the HttpSession)
• Hibernate needs a super type for entityId (including composite PK)

Given all this, I think it makes sense to enforce users of the API to pass a Serializable entityId, this allows to not close any door and to avoid any later limitation (oops, you can't activate second level caching because this pk is not Serializable). This is IMO a much better design decision than using Object. And to be honest, I do not see any annoyance with that.

This is not quite true. From the Javadoc, the signature of the relevant methods is:

public Object get(Class clazz, Serializable id) ...
public Object load(Class theClass, Serializable id) ...

(irrelevant parts and other overloaded versions omitted for brevity).

So the entity to be loaded can be of any class, only its identifer needs to be serializable.

Entities indeed net not be serializable, as per this quote from Java Persistence with Hibernate, ch. 13.3.2:

Persistent instances are stored in the second-level cache in a disassembled form. Think of disassembly as a process a bit like serialization (the algorithm is much, much faster than Java serialization, however).

So I would guess the identifiers (in the query cache) are also not serialized. I could not find any explanation on why id is declared Serializable, and lacking this, I can only guess. The API needs a type for the id parameter, which should be a common supertype of at least the frequently used identifier types Number and String, and apart from Object, Serializable is the only choice.

I think it's because of the support for caching. When using a persistent cache, or any caching that distributes object via network you need to have a way of making sure the objects can be transported in a common format which, in this case, is Java serialization.

I frankly don't see it any other way. If you are not the one defining table structure and generating insert statements to accommodate for objects, then the SQL statement generated is a string in itself and it would insert another string of text (your serialized data) into a field of a table. Whatever you insert into a database has to be a string in this case, it cannot be an object with language dependent methods, unless you explicitly design an table to store data like that.