I am working on JSF application. I want to cache some database table on periodic basis. I heard EHCache does it, but I only see its use in Hibernate. Is it possible to use EHCache in JSF application or is there some alternative for that in JSF?
if you want use EHCache in front end part you should write cache handler with
net.sf.ehcache.CacheManager or primefaces support now ehcache, if application is big, prefer to have
cache handler service which put/get/check objects from the cache.
It is your responsibility to integrate with a caching layer if none of the frameworks you use provide such an integration. You will usually do this at the service layer that computes your view objects from your stored domain objects.
Ehcache supports different caching patterns. And here again, picking the one that fits your use case is your responsibility.
Related
I am not sure whether my approach with the MVC environment in JSF is the best way to go. Since I am trying to get the most out of JSF I would like to know how my Service Layer (or Model, speaking in MVC terms) should be 'designed'.
I know the View-Controller ratio should be 1 to 1 (exceptions ruled out).
Now in what way should I design my Service Layer? Should I use one big service (don't think so)? If not, based on what should I split my services?
Note, my Service will be called from the Beans (Controllers in MVC terms) and the Service itself will call DAO's using JPA when necessary.
Thanks in advance
The service layer (the business model) should be designed around the main entity (the data model). E.g. UserService for User, ProductService for Product, OrderService for Order, etc. You should absolutely not have one huge service class or so. That's extreme tight coupling.
As to the service layer API itself, Java EE 6 offers EJB 3.1 as service layer API. In the dark J2EE ages, long time ago when EJB 2.0 was terrible to develop with, Spring was more often been used as service layer API. Some still use it nowadays, but since Java EE 6 has incorporated all the nice lessons learnt from Spring, it has become superfluous. Note that EJB (and JPA) is not available in barebones servletcontainers such as Tomcat. You'd need to install for example OpenEJB on top of it (or just upgrade to TomEE).
Regardless of the service layer API choice, best would be to keep your JSF backing bean (action)listener methods as slick as possible by performing the business job entirely in the service layer. Note that the service layer should by itself not have any JSF dependencies. So any (in)direct imports of javax.faces.* in the service layer code indicates bad design. You should keep the particular code lines in the backing bean (it's usually code which adds a faces message depending on the service call result). This way the service layer is reuseable for other front ends, such as JAX-RS or even plain servlets.
You should understand that the main advantage of the service layer in a Java EE application is the availability of container managed transactions. One service method call on a #Stateless EJB counts effectively as a single DB transaction. So if an exception occurs during one of any DAO operations using #PersistenceContext EntityManager which is invoked by the service method call, then a complete rollback will be triggered. This way you end up with a clean DB state instead of a dirty DB state because for example the first DB manipulation query succeeded, but the second not.
See also:
Creating master-detail pages for entities, how to link them and which bean scope to choose
When is it necessary or convenient to use Spring or EJB3 or all of them together?
JSF Controller, Service and DAO
The 1:1 ratio between services and model entities maybe not bad if you have few entities in your app. But if it is a big app, there would be too much services.
The number of services depends upon the use cases of the app you are designing. Once you have identified them in the analysis phase, you must group them in several groups according to their functionality. Each group of use cases will be a Service, and each use case will be a method in that service. Each Service can manage several model entities (and you have to inject in it the DAOs it needs to perform its functionality). Usually the uses cases of a Service manage model entities inter-realationated in the class diagram of the model. The Services might follow the good practice of "max cohesion / min coupling".
The ratio between DAOs and model entities is 1:1. Each DAO perform CRUD operations and queries of its entity. If a method needs to query 2 relationated entities, put it in the more suitable DAO depending on the business concepts.
In the JSF presentation layer I neither have a 1:1 ratio between pages and controllers, that would be too much controllers. I group into one contrller all the pages needed to perform the use cases of each service. So the ratio 1:1 is between controllers and services, injecting each service in the controller whose pages perform its use cases.
Of course, these are general principles. You may have some particular cases in the app that broke them, but they are few.
You might not have too much services and controllers, but not too few neither because then they would have too much logic and fields. You must acchieve a compromise.
I want to implement the cache so whenever table is updated in database ,my entity should get updated.How can i implement caching feature in spring integration ?
See the Spring Framework Caching Abstraction.
You would need some mechanism to invalidate the cache when the external resource changes.
I have written a batch application which spawns multiple threads to read assigned files and save records to database. The architecture uses Spring context and Hibernate.
Transaction is managed by Spring and I am using SessionFactory.getCurrentSession to get a session to perform a save operation for each thread.
Consider that I have a generic DAO that handles get, save, update operations and a facade to hide Hibernate implementation, how can I be assured that two threads when invoking SessionFactory.getCurrentSession() are getting their dedicated Session object to perform DB operations.
I found a post in StackOverflow where someone recommended not to use current_session_context_class=thread when using spring managed transaction. what is the default implementation used by Spring for current_session_context_class property?
Thanks in Advance!
As of Spring 2.0 Spring integrates with hibernate throuhg its own implementation(s) of the CurrentSessionContext interface provided by hibernate.
By default spring sets this to the SpringSessionContext to integrate properly. In general you don't want or need to mess with the current_session_context_class unless you are using JTA (although when using Hibernate 4 with a recent Spring version it should also just work).
I have a working knowledge of Struts2 and Spring. I want to develop an application that manages information for multiple companies. I am totally confused about what technologies are best for my application. For instance: Struts2, and Hibernate MVC with Spring.
Can somebody help me select appropriate technologies?
Here is a quick breakdown of a J2EE stack you can use:
Use Struts2 for your controller layer
Use Hibernate for your data abstraction layer. Create service interfaces for your DAO. The interfaces will allow you to use some type of RMI for services later if desired, meaning those services can run on different machines than your web app. Have concrete classes implement those interfaces. The classes will contain business logic and validation of data, and will wrap the Hibernate session. The Hibernate session is used to read/write to/from the database. Use Hibernate annotations to expedite the implementation of Hibernate beans.
Use Spring for instantiating your service classes and Struts2 actions. Configure Spring to inject service instances into your Struts2 actions. This is called dependency injection. Reference interfaces, not classes in your Struts2 action's setter methods for the DI.
Use the Struts2 tag library or JSTL in your JSP, which will be your view layer.
Use Maven for your builds and deploys.
Run Apache with mod_jk, and use Tomcat as your servlet container. mod_jk runs w/ the Apache process, and passes requests to the Tomcat servlet container, which lives in the JVM.
If your application requires search capabilities, use SOLR, a REST service built on top of Lucene.
Instead of using Struts2, you could also take a look at Apache Wicket.
I had the same question few days back and following are the links I used to make a decision - I settled for Spring MVC. Also check out Spring ROO if you are starting afresh.
Choosing the right web framework
Comparing web frameworks
What Web Application Framework?
Ultimately choice will be based on your needs - but above links discuss what parameters you should consider before choosing one.
Hope that helps.
Agree with #Simian, and add some comments and reasons.
From a technological perspective, you should use any framework that utilize modern and mature technologies, such as Struts 2, Spring MVC, Hibernate, JSF, and etc.
However, from a business perspective, you should take more emphasis on the business model that your project consist of, and the demand for the framework is easy and rapid to implement, as well as robust and easy to maintain.
Therefore, as you are familiar with Struts 2, and Spring, I recommend:
1, Use Struts 2 as the MVC framework of your project, but use AJAX if required. You can also develop your interceptors to fulfill some common requirements of your project.
(Or, if you have time, you can learn Spring MVC as it works well with Spring framework, and has better support of AJAX and RESTful. JSF is not recommended, not because it isn't a superb framework, but it use a set of complete different concepts comparing to Struts 2 and Spring MVC, and it is difficult for an unskilled person to debug )
2, Just use Spring jdbcTemplate as your data layer, use DAO pattern to decouple.
(Or , you can learn Hibernate or JPA as your ORM framework, if you have time.)
3, Use Spring IoC to manage your objects and integration with Struts 2 and Hibernate, and manage transactions with Spring's annotations.
Consider the scenario of a typical webapp with JSFs on the front and EJB 3, with Hibernate as JPA provider, talking to backend database such as mysql, etc. The main user actions are login and mostly CRUD operations (minus any D(elete) operations). And the App Server is GlassFish of course.
Given this scenario, how and where all would one go about providing caching to improve performance? From what I have googled, I have seen that hibernate provides some sort of caching through different cache providers. Is there any sort of caching that can be provided for the jsf pages? How about session beans or entity beans on the ejb side of things?
Also, I just read about memcached and was wondering if this was something to consider?
This article on second level caching by Jacob Orshalick is worth a read.
Seam has a JSF tag <s:cache> that allows page-fragment caching. The caching chapter of the Seam Docs is also worth reading.