Caching prepared statements makes sense only within a specific JDBC connection. This way, you only get something from the cached prepared statements when a connection pool is available at the ORM level. Otherwise, you get a new “physical” JDBC connection every time you create a Hibernate session (which is usually not very efficient). Without any cache pool connections, prepared statements are only useful in the scope of a single JDBC / hibernation session. This is because, without joining the connections, the “physical” connection is actually closed and will not be reused, instead a new connection will always be created using the database driver when necessary.
Another thing you need to consider is that the number of open prepared statements in a single JDBC connection is limited (the limit depends on the provider and depends on the driver implementation, as far as I know). Thus, in a join join scenario, the join implementation will probably know how many open prepared statements can be supported on each of the "physical" base JDBC pool connections. The “least used prepared statements closes first” policy is probably implemented, but this is pure speculation on my part.
Hope this makes sense. Whenever I mention the “physical” JDBC connection, I mean the actual new TCP / IP database connection. Compounds obtained by a pool of compounds typically adorn / complete the “physical”.
Edits to answer your questions more directly:
Hibernate most likely uses and caches PreparedStatements (this is a very simple JDBC optimization). The question is whether this caching occurs in operations created by the "physical" or pool providing the JDBC connection. Without pool caching, PreparedStatements only optimizes part of the execution of an application that uses a specific PreparedStatement twice in a specific Hibernate session area. With a pool, the same PreparedStatement will be (efficiently) used in many instances of a Hibernate session that will use the same underlying physical connection.
The hibernate.c3p0.max_statements property of your hibernation configuration is likely to configure an instance of the C3PO pool (which, I am sure, is automatically created for you), and this configuration has something to do with the fact about the number of open prepared ones that are limited in the “physical” JDBC connection.