• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

JPA Caching for Performance

 
Sandeep Khanzode
Greenhorn
Posts: 11
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To achieve better performance, JPA entities can be cached. Since SCEA 5 tests for Java EE 5 which has JPA 1.0 support and JPA 2.0 came much later, can we consider JPA 2.0 to be part of our solution? As JPA supports shared caching etc. If not, is it possible to include a non-standard framework like EHCache in our solution? Please discuss your thoughts on this. Thanks,
 
Marcelo Ortega
Ranch Hand
Posts: 528
Eclipse IDE Hibernate Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think it should be ok to use JPA 2.0 as I recall focusing on this particular version for part 1 (dont have my notes with me though so cant confrm). I wouldnt risk using anything outside of JEE.. but thats just me being safe
 
Rishi Shehrawat
Ranch Hand
Posts: 218
Hibernate Java Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since JPA 2.0 is not part of JEE5, I used a custom caching component. I used Ehcache as the cache provider for the custom component. I justified using Ehcache vis-a-vis custom cache implementation in design decisions.
 
Krishna Jonnalagadda
Ranch Hand
Posts: 43
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am also struggling to use a caching mechanism for assignment. How about the following two options:

1. Use a DAO,DAOFactory implementation using plain JDBC ? The petstore example uses this ...but its prior EJB 3 though ...
2. Leave this open to the developers who'll develop this..Just mention to use some caching mechanism ...

Any comments ?
 
Rishi Shehrawat
Ranch Hand
Posts: 218
Hibernate Java Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. Use a DAO,DAOFactory implementation using plain JDBC ? The petstore example uses this ...but its prior EJB 3 though ...

Given productivity gains, ease of use, etc. you should have a very good reason for not using ORM. I would not suggest using plain JDBC.

2. Leave this open to the developers who'll develop this..Just mention to use some caching mechanism ...

In my opinion, this needs to be part of the architecture & cannot be left to the developer.
 
Tad Senn
Greenhorn
Posts: 2
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rishi Shehrawat wrote:
1. Use a DAO,DAOFactory implementation using plain JDBC ? The petstore example uses this ...but its prior EJB 3 though ...

Given productivity gains, ease of use, etc. you should have a very good reason for not using ORM. I would not suggest using plain JDBC. [...]


A certain assignement has very high performance requirements and uptime ... Is that a good reason ? Or EJB 3 would be always better ?
 
Rishi Shehrawat
Ranch Hand
Posts: 218
Hibernate Java Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is a perception that hand coded JDBC is always more performant than ORM, which i feel is not completely correct. You can start with ORM, for the areas where you find that ORM is not fast enough you can use SQL as this option is also availaible when you use ORM.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic