Hibernate Cache Configuration
EHCache (org.hibernate.cache.EhCacheProvider)
OSCache (org.hibernate.cache.OSCacheProvider)
SwarmCache (org.hibernate.cache.SwarmCacheProvider)
JBoss TreeCache (org.hibernate.cache.TreeCacheProvider)
<hibernate-mapping package="com.javawhat.test">
<class name="State" table="STATE" dynamic-update="true">
<cache usage="read-only"/>
.................................................
</class>
</hibernate-mapping>
2) Activate all cache classes in hibernate.cfg.xml file (recommended), using class-cache attribute:
<hibernate-configuration>
<session-factory>
..................................
<property name="hibernate.cache.provider_class">
org.hibernate.cache.EHCacheProvider
</property>
.........................................
<class-cache class="com.javawhat.test.State" usage="read-only" />
</session-factory>
</hibernate-configuration>
<diskStore path="java.io.tmpdir"/>
<defaultCache maxElementsInMemory="10000" eternal="false" timeToIdleSeconds="120"
timeToLiveSeconds="120" overflowToDisk="true" diskPersistent="false"
diskExpiryThreadIntervalSeconds="120" memoryStoreEvictionPolicy="LRU" />
<cache name="com.javawhat.test.State" maxElementsInMemory="55"
eternal="true" overflowToDisk="false" />
</ehcache>
how you maintain session if your browser is not support session?
You need to append the jsessionid to all the URL's involved in your webapplication which are supposed to be invoked by the client. This includes the redirect URL's and the links in the JSP page.
In case of a redirect URL, you need to use HttpServletResponse#encodeRedirectURL() first:
response.sendRedirect(response.encodeRedirectURL("page.jsp"));
In case of links in a JSP page, you basically need to pass those URL's through HttpServletResponse#encodeURL() first. You can do this with help of JSTL's (just drop jstl-1.2.jar in /WEB-INF) <c:url> tag, it will behind the scenes pass the URL through the aforementioned method:
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
..............................................
<a href="<c:url value="page1.jsp" />">link1</a>
<a href="<c:url value="page2.jsp" />">link2</a>
..............................................
<form action="<c:url value="servlet" />" method="post">
..............................................
</form>
Answer:
We know that session tracking uses cookies by default to associate a session identifier with a unique user. If the browser does not support cookies, or if cookies are disabled, you can still enable session tracking using URL rewriting.
URL rewriting essentially includes the session ID within the link itself as a name/value pair. However, for this to be effective, you need to append the session ID for each and every link that is part of your servlet response.
Adding the session ID to a link is greatly simplified by means of of a couple of methods: response.encodeURL() associates a session ID with a given URL, and if you are using redirection, response.encodeRedirectURL() can be used by giving the redirected URL as input.
Both encodeURL() and encodeRedirectedURL() first determine whether cookies are supported by the browser; if so, the input URL is returned unchanged since the session ID will be persisted as a cookie.
Consider the following example, in which two JSP files, say hello1.jsp and hello2.jsp, interact with each other. Basically, we create a new session within hello1.jsp and place an object within this session. The user can then traverse to hello2.jsp by clicking on the link present within the page.Within hello2.jsp, we simply extract the object that was earlier placed in the session and display its contents. Notice that we invoke the encodeURL() within hello1.jsp on the link used to invoke hello2.jsp; if cookies are disabled, the session ID is automatically appended to the URL, allowing hello2.jsp to still retrieve the session object.
Try this example first with cookies enabled. Then disable cookie support, restart the brower, and try again. Each time you should see the maintenance of the session across pages.
Do note that to get this example to work with cookies disabled at the browser, your JSP engine has to support URL rewriting.
hello1.jsp
<%@ page session="true" %>
<%
Integer num = new Integer(100);
session.putValue("num",num);
String url =response.encodeURL("hello2.jsp");
%>
<a href='<%=url%>'>hello2.jsp</a>
hello2.jsp
<%@ page session="true" %>
<%
Integer i= (Integer )session.getValue("num");
out.println("Num value in session is "+i.intValue());
%>
Cookies
Using cookies is the simplest and most common way to track HTTP sessions, because it requires no special programming to track sessions. When session management is enabled and a client makes a request, the HttpSession object is created and a unique session ID is generated for the client and sent to the browser as a cookie. On subsequent requests to the same hostname, the browser continues to send the same session ID back as a cookie and the Session Manager uses the cookie to find the HttpSession associated with the client.
URL rewriting
There are situations in which cookies do not work. Some browsers do not support cookies. Other browsers allow the user to disable cookie support. In such cases, the Session Manager must resort to a second method, URL rewriting, to manage the user session.
With URL rewriting, links returned to the browser or redirect have the session ID appended to them. For example, the following link in a Web page:
<a href="/store/catalog">
is rewritten as:
<a href="store/catalog;jsessionid=DA32242SSGE2">
When the user clicks the link, the rewritten form of the URL is sent to the server as part of the client's request. The Web container recognizes ;jsessionid=DA32242SSGE2 as the session ID and saves it for obtaining the proper HttpSession object for this user.
Note: Do not make assumptions about the length or exact content of the ID that follows the equals sign (=). In fact, the IDs are often longer than what this example shows.
An application that uses URL rewriting to track sessions must adhere to certain programming guidelines. The application developer needs to:
• Program session servlets to encode URLs
• Supply a servlet or JSP file as an entry point to the application
• Avoid using plain HTML files in the application
Program session servlets to encode URLs
Depending on whether the servlet is returning URLs to the browser or redirecting them, include either the encodeURL() or encodeRedirectURL() method in the servlet code. Here are examples demonstrating what to replace in your current servlet code.
Rewrite URLs to return to the browser
Suppose you currently have this statement:
out.println("<a href=\"/store/catalog\">catalog<a>");
Change the servlet to call the encodeURL method before sending the URL to the output stream:
out.println("<a href=\"");
out.println(response.encodeURL ("/store/catalog"));
out.println("\">catalog</a>");
Rewrite URLs to redirect
Suppose you currently have the following statement:
response.sendRedirect (http://myhost/store/catalog);
Change the servlet to call the encodeRedirectURL method before sending the URL to the output stream:
response.sendRedirect (response.encodeRedirectURL (http://myhost/store/catalog));
encodeURL() and encodeRedirectURL():
The encodeURL() and encodeRedirectURL() methods are part of the HttpServletResponse object. These calls check to see if URL rewriting is configured before encoding the URL. If it is not configured, they return the original URL.
If both cookies and URL rewriting are enabled and response.encodeURL() or encodeRedirectURL() is called, the URL is encoded, even if the browser making the HTTP request processed the session cookie.
You can also configure session support to enable protocol switch rewriting. When this option is enabled, the product encodes the URL with the session ID for switching between HTTP and HTTPS protocols.
Supply a servlet or JSP file as an entry point
The entry point to an application (such as the initial screen presented) may not require the use of sessions. However, if the application in general requires session support (meaning some part of it, such as a servlet, requires session support) then after a session is created, all URLs must be encoded in order to perpetuate the session ID for the servlet (or other application component) requiring the session support.
The following example shows how Java code can be embedded within a JSP file:
<% response.encodeURL ("/store/catalog"); %>
Question: Difference between forward and sendRedirect?
Answer:
When you invoke a forward request, the request is sent to another resource on the server, without the client being informed that a different resource is going to process the request. This process occurs completely with in the web container.
When a sendRedirtect method is invoked, it causes the web container to return to the browser indicating that a new URL should be requested. Because the browser issues a completely new request any object that are stored as request attributes before the redirect occurs will be lost. This extra round trip a redirect is slower than forward.
- Controlling the second-level cache - hibernate.cache.use_second_level_cache is used to enable/disable second-level cache globally by setting true/false.
- Setting up a local cache provider - hibernate.cache.provider_class is used to define cache provider.
EHCache (org.hibernate.cache.EhCacheProvider)
OSCache (org.hibernate.cache.OSCacheProvider)
SwarmCache (org.hibernate.cache.SwarmCacheProvider)
JBoss TreeCache (org.hibernate.cache.TreeCacheProvider)
- Activating second-level caching classes in one of the following ways:
<hibernate-mapping package="com.javawhat.test">
<class name="State" table="STATE" dynamic-update="true">
<cache usage="read-only"/>
.................................................
</class>
</hibernate-mapping>
2) Activate all cache classes in hibernate.cfg.xml file (recommended), using class-cache attribute:
<hibernate-configuration>
<session-factory>
..................................
<property name="hibernate.cache.provider_class">
org.hibernate.cache.EHCacheProvider
</property>
.........................................
<class-cache class="com.javawhat.test.State" usage="read-only" />
</session-factory>
</hibernate-configuration>
- Configure cache provider using configuration file. Here is using EHCache as example:
<diskStore path="java.io.tmpdir"/>
<defaultCache maxElementsInMemory="10000" eternal="false" timeToIdleSeconds="120"
timeToLiveSeconds="120" overflowToDisk="true" diskPersistent="false"
diskExpiryThreadIntervalSeconds="120" memoryStoreEvictionPolicy="LRU" />
<cache name="com.javawhat.test.State" maxElementsInMemory="55"
eternal="true" overflowToDisk="false" />
</ehcache>
how you maintain session if your browser is not support session?
You need to append the jsessionid to all the URL's involved in your webapplication which are supposed to be invoked by the client. This includes the redirect URL's and the links in the JSP page.
In case of a redirect URL, you need to use HttpServletResponse#encodeRedirectURL() first:
response.sendRedirect(response.encodeRedirectURL("page.jsp"));
In case of links in a JSP page, you basically need to pass those URL's through HttpServletResponse#encodeURL() first. You can do this with help of JSTL's (just drop jstl-1.2.jar in /WEB-INF) <c:url> tag, it will behind the scenes pass the URL through the aforementioned method:
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
..............................................
<a href="<c:url value="page1.jsp" />">link1</a>
<a href="<c:url value="page2.jsp" />">link2</a>
..............................................
<form action="<c:url value="servlet" />" method="post">
..............................................
</form>
Answer:
We know that session tracking uses cookies by default to associate a session identifier with a unique user. If the browser does not support cookies, or if cookies are disabled, you can still enable session tracking using URL rewriting.
URL rewriting essentially includes the session ID within the link itself as a name/value pair. However, for this to be effective, you need to append the session ID for each and every link that is part of your servlet response.
Adding the session ID to a link is greatly simplified by means of of a couple of methods: response.encodeURL() associates a session ID with a given URL, and if you are using redirection, response.encodeRedirectURL() can be used by giving the redirected URL as input.
Both encodeURL() and encodeRedirectedURL() first determine whether cookies are supported by the browser; if so, the input URL is returned unchanged since the session ID will be persisted as a cookie.
Consider the following example, in which two JSP files, say hello1.jsp and hello2.jsp, interact with each other. Basically, we create a new session within hello1.jsp and place an object within this session. The user can then traverse to hello2.jsp by clicking on the link present within the page.Within hello2.jsp, we simply extract the object that was earlier placed in the session and display its contents. Notice that we invoke the encodeURL() within hello1.jsp on the link used to invoke hello2.jsp; if cookies are disabled, the session ID is automatically appended to the URL, allowing hello2.jsp to still retrieve the session object.
Try this example first with cookies enabled. Then disable cookie support, restart the brower, and try again. Each time you should see the maintenance of the session across pages.
Do note that to get this example to work with cookies disabled at the browser, your JSP engine has to support URL rewriting.
hello1.jsp
<%@ page session="true" %>
<%
Integer num = new Integer(100);
session.putValue("num",num);
String url =response.encodeURL("hello2.jsp");
%>
<a href='<%=url%>'>hello2.jsp</a>
hello2.jsp
<%@ page session="true" %>
<%
Integer i= (Integer )session.getValue("num");
out.println("Num value in session is "+i.intValue());
%>
Cookies
Using cookies is the simplest and most common way to track HTTP sessions, because it requires no special programming to track sessions. When session management is enabled and a client makes a request, the HttpSession object is created and a unique session ID is generated for the client and sent to the browser as a cookie. On subsequent requests to the same hostname, the browser continues to send the same session ID back as a cookie and the Session Manager uses the cookie to find the HttpSession associated with the client.
URL rewriting
There are situations in which cookies do not work. Some browsers do not support cookies. Other browsers allow the user to disable cookie support. In such cases, the Session Manager must resort to a second method, URL rewriting, to manage the user session.
With URL rewriting, links returned to the browser or redirect have the session ID appended to them. For example, the following link in a Web page:
<a href="/store/catalog">
is rewritten as:
<a href="store/catalog;jsessionid=DA32242SSGE2">
When the user clicks the link, the rewritten form of the URL is sent to the server as part of the client's request. The Web container recognizes ;jsessionid=DA32242SSGE2 as the session ID and saves it for obtaining the proper HttpSession object for this user.
Note: Do not make assumptions about the length or exact content of the ID that follows the equals sign (=). In fact, the IDs are often longer than what this example shows.
An application that uses URL rewriting to track sessions must adhere to certain programming guidelines. The application developer needs to:
• Program session servlets to encode URLs
• Supply a servlet or JSP file as an entry point to the application
• Avoid using plain HTML files in the application
Program session servlets to encode URLs
Depending on whether the servlet is returning URLs to the browser or redirecting them, include either the encodeURL() or encodeRedirectURL() method in the servlet code. Here are examples demonstrating what to replace in your current servlet code.
Rewrite URLs to return to the browser
Suppose you currently have this statement:
out.println("<a href=\"/store/catalog\">catalog<a>");
Change the servlet to call the encodeURL method before sending the URL to the output stream:
out.println("<a href=\"");
out.println(response.encodeURL ("/store/catalog"));
out.println("\">catalog</a>");
Rewrite URLs to redirect
Suppose you currently have the following statement:
response.sendRedirect (http://myhost/store/catalog);
Change the servlet to call the encodeRedirectURL method before sending the URL to the output stream:
response.sendRedirect (response.encodeRedirectURL (http://myhost/store/catalog));
encodeURL() and encodeRedirectURL():
The encodeURL() and encodeRedirectURL() methods are part of the HttpServletResponse object. These calls check to see if URL rewriting is configured before encoding the URL. If it is not configured, they return the original URL.
If both cookies and URL rewriting are enabled and response.encodeURL() or encodeRedirectURL() is called, the URL is encoded, even if the browser making the HTTP request processed the session cookie.
You can also configure session support to enable protocol switch rewriting. When this option is enabled, the product encodes the URL with the session ID for switching between HTTP and HTTPS protocols.
Supply a servlet or JSP file as an entry point
The entry point to an application (such as the initial screen presented) may not require the use of sessions. However, if the application in general requires session support (meaning some part of it, such as a servlet, requires session support) then after a session is created, all URLs must be encoded in order to perpetuate the session ID for the servlet (or other application component) requiring the session support.
The following example shows how Java code can be embedded within a JSP file:
<% response.encodeURL ("/store/catalog"); %>
Question: Difference between forward and sendRedirect?
Answer:
When you invoke a forward request, the request is sent to another resource on the server, without the client being informed that a different resource is going to process the request. This process occurs completely with in the web container.
When a sendRedirtect method is invoked, it causes the web container to return to the browser indicating that a new URL should be requested. Because the browser issues a completely new request any object that are stored as request attributes before the redirect occurs will be lost. This extra round trip a redirect is slower than forward.
No comments:
Post a Comment