But the other points that Shailesh brought up are valid. You do not hvae to cache anything, and the only object that will take really any memeory, besides the loaded data is the Factory class EntityManagerFactory. But that also depends on how many mapped classes you need?
You can definitely use JPA and find it easier to maintain than JDBC in your memory critical situation, but you do have to know how to minimize the JPA footprint well.
Please read Mark's reply. As he said it all depends on how many mapped classes you have in your application. If you are using JDBC and mapping the resultset to POJO's then you do not have much difference on memory footprint. If you are just traversing through your result set in your jsp and displaying them you are not creating any additional objects so your memory foot print is small. It also depends on how huge your result set is, how many columns it has etc...
To summarize... There is not much of a difference if you use JPA or convert your resultset into Collection of POJO's yourself. If you are worried about query parsing... then it is parsed only once and it works exactly the same as JDBC. Only with JDBC you have to write a lot of code.
If you want metrics... Google is your best friend!
simply do not use JPA. It has enormous footprint. Also, you have to consider for each entity class:
-classes are redefined in memory -metadata has be loaded and hold in memory -adapter classes for DB -JPA implementation objects -db metadata -garbage collection -unnecessary fetched objects -the list goes on...