Hibernate persistOnFlush over 100000 Events in dynaTrace
Hello Guys,
I have with dynaTrce 5.6 the problem that some pure paths get cut because dynaTrace captures thousands of hibernate flush events. Has anybody already a solution for this?
Thanks,
Paul
Yeah that makes sense to me. Basically I want to know how many objects are currently attached / loaded. As I see only one "select". The problem is that one an the same value is written 25145 times (still increasing) into the "n" table.
Basically Book --> ISBN. Isbn is always added on a update, even if it is the same. Does not look bad in the SQL. One simple insert statement. But it grows over time and usage.
If this book is now loaded, it contains a lot of ISBNs – having the save value. I discovered it as I have seen that the response is very large, more then 1MB of a simple book record is a little to much 
.
Does this make sense?
makes sense. Would you be wiling to share PurePaths with me of this? Maybe even a "Before" and "After-the-fix" PurePath? I am always looking for these "data driven" problem pattern examples
I yes, the management I guess not – as the code can be decompiled if I upload the pure paths 
.
Exported PurePaths DO NOT contain the byte code. The decompile feature only works on your live System Profile. So - should not be a problem. Also - you can send it to me directly via email (firstname.lastname@compuware.com) in case you dont want to share it with a larger public
Okay I removed it and the problem is gone BUT, (where is always a BUT) actually it pointed out a software bug. I digged deeper into the code – and tada the developer did an error:
A 1 : n relation table is growing "out of limits"
the only point where this is now is visible is the "io write" as it is a remote call. Not sure if I really want to remove it then?
Is were a way to monitor large Hibernate sessions, with to many objects attached to it?
Database access should be captured with our JDBC Sensor. Looking at these PurePaths you can drill to the database dashlet and you should see the statements executed. Will this help identify the problem?
If not - which Hibernate Method did you look at to find this problem? You may just want to add a custom sensor for that method that allows you to see this pattern - but exclude (=not place) the Hibernate Sensor Pack in general
It comes with dynaTrace - but - starting with dynaTrace 5.x we do not automatically "place" it for new System PRofiles. We also recommend to unplace this Sensor Pack as Auto Sensors are doing a great job to capture Hibnerate performance problems
The solution is to disable the Hibernate Sensor. With new System Profiles we actually dont activate this Sensor Pack any longer as our Auto Sensors will pickup slow Hibernate calls for you anyway without "filling" your PurePath with lots of these nodes
