That is quite strange. In most cases, Hibernate ORM is seen slow when there are combinatorial issues. That means that the more data the slower in an exponential rate. But you experience a significant slowness of one specific reading (same all the time from what I understand).

My initial reaction was a resource contention and release at the JDBC driver level (or Hibernate ORM but I don't see why). The fact that it fails at the same time constantly tends to eliminate a classical GC issue - too predictable ;P - so I'd tend to explore the following two:

1. change the driver
2. Look at Item id 1060 to 1070 / platId 6 to see if one of them has an unusually big data
3. Look at Item's mapping and see if anything is wrong

For 1. I'd recommend you try http://jtds.sourceforge.net. While the Microsoft JDBC driver is generally of pretty good quality, jtds used to be best before they really rewrote theirs.
For 3. t could be complex mapping of one sort or another. In particular it seems Item has a composite identifier and its types are weird (at least their toLoggableString implementation):

• can you show Item's code
• can you show the composite id code I'm interested in the equals / hasCode impl specifically
• can you show the custom types code if you have any ( Unknown macro: {plantId=6, itemId=1064}

  and the following empty string are suspicious )