<span style="border-collapse:collapse">I&#39;m looking into some performance improvements with a one to many relationship that has a lot of objects on the to-many side.<div><br></div><div>When I&#39;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.</div>

<div><br></div><div>Specifically the transactionContext.managedFlush(); call....</div><div><br></div><div>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.</div>
<div><br></div><div>I don&#39;t see anything in the log telling me there&#39;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.<br>
</div><div><br></div><div>Is this something related to optimistic locking? ie. it&#39;s fetching everyting back to see what&#39;s changed relative to the transaction it&#39;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?</div>
<div><br></div>
</span>