When Hibernate loads an object into a Session it creates a state snapshot of the current database state of the object, so that it can perform dirty checking against the snapshot.
As a read only object will never be modified, this snapshot is not needed and memory can be saved.
Hibernate allows you to create types and override the fetching/saving metods of the types.
Create a type, e.g., InsertableOnly, which on the fetch sets throws away the database value.
Assuming your value is an Integer because you represent prices in cents to avoid rounding issues:
class InsertOnlyInteger extends org.hibernate.type.IntegerType {
public Object get(ResultSet rs, String name) throws SQLException {
return null;
}
}
Then make the Hibernate type of the attribute InsertOnlyInteger (with xml or annotation, as it suits you).
The pooled-lo optimizer uses the current database sequence value as the lowest in-memory boundary, so other systems may freely use the next sequence values without risking identifier clashing
For the save() operation to be cascaded, you need to enable CascadeType.SAVE_UPDATE, using the proprietary Hibernate Cascade annotation, since save() is not a standard JPA operation. Or you need to use the persist() method, and not the save() method.
From the community documentation:
hibernate.hbm2ddl.auto Automatically validates or exports schema DDL to the database when the SessionFactory is created. With create-drop, the database schema will be dropped when the SessionFactory is closed explicitly.
e.g. validate | update | create | create-drop
So the list of possible options are,
validate: validate the schema, makes no changes to the database.
update: update the schema.
create: creates the schema, destroying previous data.
create-drop: drop the schema at the end of the session.
When using spring and spring managed transactions never mess around with the hibernate.current_session_context_class property UNLESS you are using JTA.
Naturally I want to have a transactional DBMS, so I always pick InnoDB as the MySQL storage engine. I also want UTF-8 support because the content I store is entered by users from all over the world. Hence not all of the tips and tricks shown here might be relevant for you, in fact, if you are happy with your system in production, do not change anything. Also note that many of these customizations are only relevant if you let Hibernate generate your MySQL DDL and schema for you.