Additional info on restrictions usage:

1) Seam forces one EL expression per restriction.
2) can combine a EL expression and constants in one restriciton
Example:
“name like concat(lower(#{customer.name}),’%') or description like ‘ILI%’)”
3) Multiple restrictions are treated as “and” operation.

If you would like to know more about the Equals and Hashcode importance for an ORM Click here.

To summarize the ORM implementation, There are two types of keys: Technical Keys and Business keys.

Technical keys are the primary key on the for a table to uniquely identify a database row, these numbers are auto generated sequence number (Item Unique IDentification/ IUID).

Business keys are the Business primary (/ composite) keys which uniquely identify the business objects in the database tables.

One of the important factor while writing a equals and hashcode method is to decide on what attributes needs to go into these methods; Some guidelines for deciding the attributes for Equals and hashcode methods.

• It is not necessary to cover all the attributes in Business Objects in equals/ hashcode methods.
• Include the Technical Keys and Business keys in equals and hashcode methods.
• Equals and hashcode methods should take care of the null cases.

Implementation wise, Apache commons-lang has a very good implementation for hashcode and equals method. Here’s an example of equals and hashcode methods using the apache commons-lang.

@Entity
@Table(name = "APP_CONFIGURATION")
@SequenceGenerator(name = "OPS_SEQ", sequenceName = "SQ_CONFIGURATION_CNTR")
public class ConfigurationBo extends AbstractBo {

private static final long serialVersionUID = -5098377177228374794L;

@Column(name = “ITEMNAME”, length = 100)
private String name;

@Column(name = “STRINGVALUE”, length = 100)
private String stringValue;

@Column(name = “INTVALUE”)
private Integer intValue;

@Column(name = “TYPENAME”, length = 20)
private String type;

public Integer getIntValue() {
return intValue;
}

public void setIntValue(Integer intValue) {
this.intValue = intValue;
}

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}

public String getStringValue() {
return stringValue;
}

public void setStringValue(String stringValue) {
this.stringValue = stringValue;
}

public String getType() {
return type;
}

public void setType(String type) {
this.type = type;
}

/**
* {@inheritDoc}
*/
@Override
public boolean equals(Object obj) {
if (this == obj) {
return true;
}
if (!(obj.getClass() == this.getClass())) {
return false;
}
ConfigurationBo other = (ConfigurationBo) obj;

return new EqualsBuilder()
.appendSuper(super.equals(obj))
.append(this.name, other.name)
.append(this.type, other.type)
.isEquals();
}

/**
* {@inheritDoc}
*/
@Override
public int hashCode() {
return new HashCodeBuilder()
.appendSuper(super.hashCode())
.append(this.name)
.append(this.type)
.toHashCode();
}

/**
* {@inheritDoc}
*/
@Override
public String toString() {
return super.toString() + “[name=” + name + “, type=” + type + “]”;
}

}

There is no pagination concept implemented for this search/ problem, its a logical thing to say this search program is using whole lots of memory and slow. Assuming the search queries are already fine-tuned, Slowness can be mainly attributed to the HTML rendering by the browser. IE browser render the complete HTML and then displays it to the user so the slowness can be easily be found compared to Firefox 2, where the browser starts displaying the data as it receives (rather completely render it and displays it).

Given this background, Now we started seriously looking at pagination as the only option. In pagination, could think three approaches as a potential solutions

• Real time pagination on the server side.
• Criteria Caching based pagination on Server side.
• Pagination on the UI front.

Lets go in details of each one of them.

Real time pagination on the server side :

This is an approach where from the UI, always pass the search criteria plus the page start record and the end record (or size of the page). So your server implementation will have these two extra arguments along with your query and returns you only the required result set which needs to be passed to front end.

On the implementation front, you could handle this scenario at two levels

• Write a stored procedure which takes your criteria and start and end record (or Size) for the page as argument and using ‘cursors’ you can return only the required result set, for more details on oracle specific result set using cursor click here
• Say you are using ORM tools like hibernate, they make our life even easier you could try something like
  

Query q = s.createQuery( “your query….” );
q.setMaxResults(PAGE_SIZE);
q.setFirstResult(PAGE_SIZE * pageNumber);
List page = q.list();

• For more details on this hibernate approach click here

Lets looks at the pros and cons of this approach

• Its a real time pagination search, say your query is based on order by name, on the first page we show say 25 records, in the mean while say another user deletes few records (say 20 to 25th record gets deleted), now when the first user click the next button, the request goes as original criteria and retrieve the records from 26th to 50th record and we return 26 to 50 th records (because of the deletion, ideally we should have displayed from 20th to 45th records), essentially now we are not showing 5 records this is a disadvantage. For the same example, addition of records ‘could’ be an advantage for this approach.

Criteria Caching based pagination on Server side

This is an approach where all records matching to the search criteria will be fetched from the database to the the server and cached. Caching is based the search criteria and a timeout period.

From the UI point of view, request will contain the search criteria plus the start record and the size( r the end record) to be fetched.

Lets looks at the pros and cons of this approach

• This solution should fairly work for most of the search cases, unless you have a requirement for real time pagination.
• When Caching is considered, Caching algorithm plays an important role and this also has to take care of the timeout period and the memory allocated for the caching mechanism.
• Arriving on the timeout period is quite crucial as this directly impacts your performance of the search. Too low timeout (is very near to real time pagination case) will cause too many hits to your database and can cause slowness also has the drawbacks of real time pagination. Too long timeout period will have the drawback of having out-dated data on the server cache.

Pagination on the UI front

This is an approach where all the records corresponding the search criteria will be retrieved from the database and held in the controller of the UI Framework and using custom tag libraries the records could be displayed in the Jsp/ Servlet.

Here are some of the recommendations for writing your own custom pagination tab lib

• The bean will have attributes for collection of all the records, total number of pages, records per page and start record number for the current page.
• On the first display of the page, read all the corresponding records for this page and store the bean in HTTP Session.
• On the selection of the next page, previous page, etc.,; retrieve the bean from the HTTP Session and then calculate which data needs to be displayed.

Lets looks at the pros and cons of this approach

• This would be dream design approach for small volume search results (where memory is not a constraint).
• Most the cases, you do have a memory constraint, hence this may not be a feasible approach.

Disadvantages:
- Hibernate Beans are not automatically ‘locked’ for others while used during a transaction. This can lead to inconsistent data when more clients concurrently modify the same data.
-Object Pooling is an Issue