Question

I have the equivalent of the following code and hibernate configuration (basically, StreamRef belongs to tape, and has to be unique on that tape):

<class name="StreamRef" table="StreamRefToTape">
 <composite-id> <key-property name="UUID"/> 
   <key-many-to-one class="Tape" name="tape">
     <column name="Tape_TapeId" not-null="true"/>
   </key-many-to-one>
 </composite-id>
 ...</class>

 <class name="Tape" table="Tape">
 <id column="TapeId" name="tapeId"/></class>

I have millions of these StreamRef’s, and I want to save them all within the same transaction, but I also want to save on RAM during this transaction.

So I attempted the following code, my assumption being that if I turn off CacheMode, then it won’t track objects internally, so it will save a lot of RAM (this seems to help, to some degree). But when testing this hypothesis, like this:

 session = sessionFactory.openSession();
 session.setCacheMode(CacheMode.IGNORE);   // disable the first level cache
 session.beginTransaction();
 Tape t = new Tape();
 StreamRef s1 = new StreamRef("same uuid");
 StreamRef s2 = new StreamRef("same uuid"); // force a primary key collision
 session.saveOrUpdate(t);
 for(StreamRef s : t.getStreams()) {
     session.save(s);
 }
 session.commit();

I would have expected this to not raise because I turned off CacheMode (but it raises a NonUniqueObjectException https://gist.github.com/4542569 ). Could somebody please confirm that 1) the hibernate internal cache is not disable-able? and 2) this exception has nothing to do with CacheMode? Is there any way to accomplish what I want here (to not use up tons of hibernate RAM within a transaction?)

somewhat related: https://stackoverflow.com/a/3543740/32453

(As a side question…does it matter the order that setCacheMode is called vin relation to beginTransaction? I assume it doesn’t?)

Many thanks.

Answer 1

The exception makes sense. You’re violating the rules you told Hibernate you were going to play by. If you really want to do what you’ve coded you’ll need to use the StatelessSession API or createSQLQuery API. As it stands, Session.setCacheMode is for interacting with the second level cache, not the session cache.

Regarding memory usage, you’ll want to incrementally flush batches of records to disk so Hibernate can purge its ActionQueue.

Here is an example from the section on batch updates in the user’s guide:

Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();

for ( int i=0; i<100000; i++ ) {
    Customer customer = new Customer(.....);
    session.save(customer);
    if ( i % 20 == 0 ) { //20, same as the JDBC batch size
        //flush a batch of inserts and release memory:
        session.flush();
        session.clear();
    }
}

tx.commit();
session.close();

You can also read about stateless sessions in the same chapter.