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?
Show replies by date