CacheModes in Hibernate - continued

In the previous post we saw the GET and IGNORE values for CacheMode. The other values are PUT and REFRESH. Consider the below code:

CacheModes in Hibernate

Hibernate offers us a CacheMode option. This is something that allows us to control the behavior of the second level cache. Consider the below code:

Testing out the cache

In earlier posts we saw the settings needed for configuring Hibernate's second level cache and the various caches providers supported by Hibernate.
To test out the configurations for Eh Cache, I simply executed a main method to start and create a session factory.

How to cache ?

In the previous post we saw how to setup the cache provider for Hibernate. But that is not the end of the story. We need to decide what kind of concurrency we need. Does our data ever change? Can we live with stale data? All these factors are decided by the concurrency strategy we use. Hibernate provides us with four built in concurrency strategies (as of version 3.0):

Hibernate Cache Framework

The Hibernate framework comes with a complete caching system. This cache system is used to reduce the amount of SQL queries fired in the system.
The Hibernate cache is built at two levels - a first level or session cache which we saw earlier and the second level cache. While the first level cache is non optional, the second level cache needs to be configured and switched on for use.

Accesing System Properties in Java

In an earlier post we saw The ExceptionUtils class provided by the Commons Lang library. The library also provides us with a SystemUtils class - it provides us with information about the JVM in use and the underlying platform. Consider the below code:

Spring Security

All projects I have worked on included login. And roles. They were built using database tables or third party applications like LDAP or service based authentication. However the new projects starting now are going ahead with Spring Security. As I have no idea about it, I decided to give a go at understanding Spring Security.
I decided to first do a small simple web application and enable the security for it. Not spring based, simple Servlet style security.

Custom Marshaling With JAXB

Consider the below class:

@XmlRootElement
public class Person {
   private String name;
   private BigDecimal weight;
   private Date dob;

   // getters and setter
}

If we were to marshal a Person instance the generated XML would be:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<person>
   <dob>2013-06-15T13:01:35.420+05:30</dob>
   <name>Test</name>
   <weight>65.876499999999992951416061259806156158447265625</weight>
</person>

The value for dob is a little complex. Could we change this to a more suitable value ?

DataBinding Options with CXF

When using CXF, the marshaling and unmarshaling of data happens under the covers. So when we make the call through java, the request is marshaled to XML by CXF client. It sends it over the wire to the server.

Excluding a property from the ORM framework

If we have a property that does not map to any column in the table, we simply do not specify that property in our hbm files. But with JPA annotations it is a little different. A class if marked with an Entity annotation, all its properties are considered persistent by default. So how do we exclude a property ?

Can we mark entity classes as final ?

We have already seen that Hibernate extensively uses proxies. It uses proxies when we call load, it uses proxies for lazily loading associations and collections.But what if our entity class was final ?