I'm looking into some performance improvements with a one to many relationship that has a lot of objects on the to-many side.

When I'm looking at the hibernate 3.2.2a code in the tx.commit() which is taking up to and longer than 1 second to commit.

Specifically the transactionContext.managedFlush(); call....

When I look at the log I notice preparedStatements being used to query back all the destination ended objects from the database instead of hitting 2nd level cache where I know they should be.

I don't see anything in the log telling me there's a 2nd level cache miss so am I expecting the wrong thing when I expect to see 2nd level cache activity during the flushing of the transaction.

Is this something related to optimistic locking? ie. it's fetching everyting back to see what's changed relative to the transaction it's processing now? If this is the case why is it generating a separate prepared statement for each and every object on the destination end of the relationship?