Hibernate automatic versioning - Part 1

Hibernate can provide automatic versioning for the entities without you doing ANYTHING. By WITHOUT ANYTHING I really mean WITHOUT  ANYTHING ! You just have your entity classes and you wnat hibernate to provide versioning so that an update on a already changes object would not happen. This sounds exciting but in actual practise its not that very used. We'll see how and why.

If you simply want hibernate to provide automatic versioning (without addition of version column or timestamp in the correspoding table and entity) then hibernate can do this but the caveat is that object should be retrieved and modified in the same session or persistence context. This essentially means that the session must not be closed (it can be flushed though to send the changes to database).

When using this feature, Hibernate checks the current database state of the entity in question and if the earlier state ( when it was retrieved or when the last flush operation was called upon session) is different from the current database state, it concludes that the entity has been modified and throws StaleObjectException.

To enable this feature on an entity you will have to add attribute optimistic-lock="all" in the entity mapping if you are using xml based configuration or Hibernate specific annotation like below if you are using annotation approach

@Entity
@org.hibernate.annotations.Entity(
       .................
        optimisticLock = OptimisticLockType.ALL,
       ........................)

public class TestEntity{ ... }

Hibernate team does not recommend using this automatic versioning without version or timestamp column as this is bit slow and complex. Also another bigger disadvantage is that it does not work for detached objects. It works only as long as the session is not closed. For this reason too, this is not effective in long running conversations as well.

 In the next part I will explain about other better way of adding optimistic version control to your entities which uses version or timestamp column to keep track of the entity state.

Resource loading in JSF 2 - Part 1

UIComponents are central to the functioning and usability of JSF. What you see on the user agent ( for e.g, web browsers) is the markup generated by UIComponent classes and whatever is submitted through browsers in web  request is decoded by the UIComponent instances for that particular page. However for any component having slight complexity, how the markup looks like and behaves is dependent on other resources like images, javascript and stylesheet etc. So if a component author provides a component, the framework should have a mechanism of including these resources (preferably within the jar bundling the component) so that components can look and behave as desired. This way components can be self contained.

Prior to JSF 2 such a mechanism was missing. JSF 2 provides this important missing piece to enable a component to load resources uniformly from class path resources.

Typically in a web application, how static resource requests are served depends on the mapping in web.xml. Most commonly the web.xml does not contain any specific mappings for extensions of static resources like images, scripts ( for e.g., *.jpg,*.css etc). In that case a Servlet provided by container usually serves up the request. For e.g., in Tomcat such requests are served up by

How JSF recognizes that a request is for a resource depends upon the existence of string "/javax.faces.resource" in the request url. If this string is present then the JSF main Servlet "FacesServlet" considers this as a resource request and forwards it to default ResourceHandler.

Hibernate Collections implementations

So your Hibernate entity has a reference to collection of other entities mapped using Set interface (or for that matter any other collection interface). You load an entity from database and in your debugger inspect the type of the collection Hibernate is using ( assuming it is configured as eagerly loaded. Lazy loading is quite another story for another day). You expect it to be usual java implementation HashSet but you see something as PersistentSet. You are bewildered and scratching your head jump to the Hibernate manuals or different forums. Go no further ! Here is what is happening under the hood !

Whenever hibernate is used for querying an object, an entity is returned which is managed by Hibernate as long as the session in which it was queried is open. Behind the scenes Hibernate queries the database and builds the entity object. The entity might contain associations in form of Single object association or Collections. In case of collections, hibernate creates its own implementation of collection. For e.g., for a List type it creates a wrapper list Persistent List. All the java collections like Set, HashMap etc. have their corresponding implementaions in Hibernate.

The base class for all these hibernate implementations is AbstractPersistentCollection as you can see below in the type hierarchy.

You will never have to directly deal with these Hibernate classes however it's good to understand the inner working of collection mapping.

All these implementations are wrapper over the original collection in the entity (decorator pattern you see !). There are many  things for which Hibernate uses these implementations classes. One of the things Hibernate uses these implementations is to mark the collections as dirty. Whenever you add/remove an object in these collections, it marks the collection dirty and Hibernate can queue the update query later when it inspects the collection. AbstractPersistentCollection maintains a Boolean variable “dirty” to indicate this and it is updated whenever there is any change to the collection via its interface.