Stale, just to point something out since you asked about dymanic-update... Yes you might save some resources on the "front end" in terms of figuring out what changed compared to the default Hibernate diff approach. Most of the performance improvement here will be related to not having to walk these entities at flush time and attempt to calculate their dirtiness on the fly (aka, where or not an update is needed at all). From there, the time in using that information to build the dynamic SQL update statement and prepare it with the JDBC driver (which is now much less likely to find it in its cache) is generally the larger concern.
Where I think you guys will see big performance gains here is by this work really reducing the work that needs to be done during a flush.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Stale, just to point something out since you asked about dymanic-update... Yes you might save some resources on the "front end" in terms of figuring out what changed compared to the default Hibernate diff approach. Most of the performance improvement here will be related to not having to walk these entities at flush time and attempt to calculate their dirtiness on the fly (aka, where or not an update is needed at all). From there, the time in using that information to build the dynamic SQL update statement and prepare it with the JDBC driver (which is now much less likely to find it in its cache) is generally the larger concern.
Where I think you guys will see big performance gains here is by this work really reducing the work that needs to be done during a flush.