Java_J2EE_Job_Interview_Companion

Q. What is the difference between the session.get() method and the session.load() method?

Both the session.get(..) and session.load() methods create a persistent object by loading the required object from the database. But if there was not such object in the database then the method session.load(..) throws an exception whereas session.get(…) returns null.

Q. What is the difference between the session.update() method and the session.lock() method?

Both of these methods and saveOrUpdate() method are intended for reattaching a detached object. The session.lock() method simply reattaches the object to the session without checking or updating the database on the assumption that the database in sync with the detached object. It is the best practice to use either session.update(..) or session.saveOrUpdate(). Use session.lock() only if you are absolutely sure that the detached object is in sync with your detached object or if it does not matter because you will be overwriting all the columns that would have changed later on within the same transaction.

Note: When you reattach detached objects you need to make sure that the dependent objects are reattached as well.

Q. How would you reattach detached objects to a session when the same object has already been loaded into the session?

You can use the session.merge() method call.

Q. What are the general considerations or best practices for defining your Hibernate persistent classes?

A Hibernate persistent class is a Plain Old Java Object (POJO), which has not interfaces to be implemented and no persistent superclass to be extended. The following are the requirements and best practices (all are not strict requirements) to consider for your Hibernate persistent classes:

1.You must have a default no-argument constructor for your persistent classes and there should be getXXX() (i.e accessor/getter) and setXXX( i.e. mutator/setter) methods for all your persistable instance variables.

2.You should implement the equals() and hashCode() methods based on your business key and it is important not to use the id field in your equals() and hashCode() definition if the id field is a surrogate key (i.e. Hibernate managed identifier). This is because the Hibernate only generates and sets the field when saving the object.

Car car = session.load(Car.class, carId);

car.getParts().add(new Part(“Steering”)); // adds a new entity with id = null (if Integer) // or id = 0 (if primitive int)

car.getParts().add(new Part(“Accelerator”));// has id = null too so overwrites last added // object in the Set.

Alternatively if you use manually assigned id fields then you can use your id field in your equals() and hashCode() methods but you must make sure to set the id field prior to adding the object to the Set and it is quite difficult to guarantee this in most applications.

Car car = session.load(Car.class, carId);

Part part1 = new Part(“Steering”);

So to avoid the problem of inadvertently not setting the id prior to adding the object to the Set, it is recommended to use the “semi” unique business key (i.e natural key) to implement equals() and hashCode() methods.

3.It is recommended to implement the Serializable interface. This is potentially useful if you want to migrate around a multi-processor cluster.

4.The persistent class should not be final because if it is final then lazy loading cannot be used by creating proxy objects.

5.Use XDoclet tags for generating your *.hbm.xml files or Annotations (JDK 1.5 onwards), which are less verbose than *.hbm.xml files.

Q. What is the difference between an object identity and a database identity?

Q. What are the important considerations in writing your equals() & hashCode() methods?

1.Use your semi unique business keys. For example you can use the following immutable fields (i.e. instance variables) as your business keys in your Car persistence class: name, model and createddate. You need to make sure that the fields used in your equals() method must be used in your hashCode() method as well.

2.If two objects are equal i.e. car1.equals(car2) returns “true” then car1.hashCode() == car2.hashCode() must return “true” as well. But if two objects are not equal i.e. car1.equals(car2) returns “false” then car1.hashCode() == car2.hashCode() can return either “true” or “false”. Refer Q19, Q20 in Java section for a discussion on equals() and hashCode() contract.

3.When referring to fields (i.e. instance variables) of the argument object, always use the accessor methods rather than directly using the instance variables because your supplied argument object might be a proxy object rather than the actual object. For example:

public boolean equals(Object supplied) {

}

if (other == null) { return false;

}

if(! (other instanceOf Car) ) { return false;

}

final Car car2 = (Car) supplied;

if( this.name.equals (car2.getName()) && this.model.equals (car2.getModel()) && this.createdDate.equals (car2.getCreatedDate()) ) {

return true;

}

else {

return false;

}

}

Need to make sure that all the three fields used in equals() method are used in hashCode() method as well.

public int hashCode() {

int hashCode = name.hashCode() * 11;

hashCode = hashCode + model.hashCode() * 17; hashCode = hashCode + createdDate.hashCode() * 29; return hashCode;

Vehicle table and 3 entity subclasses representing the Car, Van and Bus tables. If your superclass Vehicle is abstract, then map it with abstract=”true”.

Finally, you could also mix table per class hierarchy strategy with table per subclass strategy.

Q 16: Explain some of the pitfalls of Hibernate and explain how to avoid them? Give some tips on Hibernate best practices? FAQ

A 16:

Pitfalls on Hibernate and how to avoid them:

O/R mapping framework like Hibernate is well suited for read Æ modify Æ write centric applications and not suited for write centric applications (i.e. batch processes with large data sets like 5000 rows or more) where data is seldom read.

Use the ThreadLocal session pattern when obtaining Hibernate session objects (Refer Q15 in Emerging Technologies/Frameworks). This is important because Hibernate’s native API does not use the current thread to maintain associations between session and transaction or between session and application thread. Spring ORM support for Hibernate can not only take care of the above pitfall but also can improve productivity.

Handle resources properly by making sure you properly flush and commit each session object when persisting information and also make sure you release or close the session object when you are finished working with it. Most developers fall into this pitfall. If you pass a connection object to your session object then remember to issue session.close().close () which will first release the connection back to the pool and then will close the session. If you do not pass a connection object then issue session.close() to close the session.

Use lazy associations when you use relationships otherwise you can unwittingly fall into the trap of executing unnecessary SQL statements in your Hibernate applications. Let us look at an example: Suppose we have a class Employee with many-to-one relationship with class Department. So one department can have many employees. Suppose we want to list the name of the employees then we will construct the query as follows:

Query query = session.createQuery(“from Employee emp”); List list = query.list();

Hibernate will generate the following SQL query:

SELECT <fields> from Employee;

If it only generates the query above then it is okay and it serves our purpose, but we get another set of SQL queries without asking it to do anything. One for each of the referenced departments in Department table. If you had 5 departments then the following query will be executed 5 times with corresponding department id. This is the N+1 selects problem. In our example it is 5 + 1. Employee table is queried once and Department table is queried 5 times.

SELECT <fields> from Department where DEPARTMENT.id=?

Solution is to make the Department class lazy (in Hibernate 3.0 the default value for lazy attribute is “true”), simply by enabling the lazy attribute in the Department’s hbm.xml mapping definition file, which will result in executing only the first statement from the Employee table and not the 5 queries from the Department table.

<class name=”com.Department” table=”Department” lazy=”true” > …. </class>

Only one query is required to return an employee object with its department initialized. In Hibernate, lazy loading of persistent objects are facilitated by proxies (i.e. virtual proxy design pattern). In the above example you have a Department object, which has a collection of Employee objects. Let’s say that Employee objects are lazy loaded. If you make a call department.getEmployees() then Hibernate will load only the employeeIDs and the version numbers of the Employee objects, thus saving loading of individual objects until later. So what you really have is a collection of proxies not the real objects. The reason being, if you have hundreds of employees for a particular department then chances are good that you will only deal with only a few of them. So, why unnecessarily instantiate all the Employee objects? This can be a big performance issue in some situations.

Avoid N+1 selects problem: Having looked at the N+1 problem occurring inadvertently due to not having a lazy association in the previous example, now what if we need the Departmental information in addition to the Employee details. It is not a good idea to execute N+1 times.

334 Emerging Technologies/Frameworks…

<class name=”com.Department” table=”Department” lazy=”true” > …. </class>

Now to retrieve Departmental info you would:

Query query = session.createQuery(“from Employee emp”);

List list = query.list();

Iterator it = list.iterator();

while(iter.hasNext()) {

Employee emp = (Employee) it.next();

emp.getDepartment().getName(); //N+1 problem. Since Department is not already loaded so

//additional query is required for each department.

}

The solution is to make sure that the initial query retrieves all the data needed to load the objects by issuing a HQL fetch join (eager loading) as shown below:

“from Employee emp join fetch emp.Department dept”

The above HQL results in an inner join SQL as shown below:

SELECT <fields from Employee & Department> FROM employee

inner join department on employee.departmentId = department.id.

Alternatively you can use a criteria query as follows:

Criteria crit = session.createCriteria(Employee.class); crit.setFetchMode(“department”, FetchMode.EAGER);

The above approach creates the following SQL:

SELECT <fields from Employee & Department> FROM employee

left outer join department on employee.departmentId = department.id where 1=1;

Tips on Hibernate best practices:

•Define equals() and hashCode() methods with the semi unique business key attributes (should not use the indentifier property) for the entity objects that are stored in a collection like a Set. Follow the equals() & hashCode() contracts.

•Leave all your associations by default as lazy and also specify an appropriate batch-size for performance. Also make it a conscious choice to eagerly fetch data only for specific use cases.

•Define your session management (i.e. use of detached objects etc), caching (both 1st level & 2nd level cache) and flush (i.e. auto-flush vs defining your own synchronization points etc) strategies early in your project.

•Prefer using bi-directional associations for a one-to-many association with an inverse=”true” attribute for efficiency. Also use batch updates/inserts for bulk inserts/updates (may even consider using Stored Procedures directly for large data).

•Where possible use surrogate key as your identifier as opposed to using composite keys.

•Keep your database transactions as short as possible with the use of detached objects and also understand the Hibernate object life cycles and states.

•Use Spring ORM support for hibernate, which reduces the code size by almost a half and provides additional benefits such as easier testing, consistent exception hierarchy and management of Hibernate resources. Spring exceptions are unchecked and hence you do not have to write any try{} catch{} and finally{} semantics and also you can manage the transactions declaratively via Spring transaction management (Refer Q43 in Enterprise section) using Spring AOP (Refer Q3 in Emerging Technologies/Frameworks section).

Q 17: Give an overview of the Spring framework? What are the benefits of Spring framework? FAQ

A 17: The Spring framework is the leading full-stack Java/J2EE application framework. Unlike other frameworks, Spring does not impose itself on the design of a project due to its modular nature and, it has been divided logically into

injections) business objects and DAO objects into your JUnit test cases and later on if remote access is required, can be deployed inside the EJB container with a thin layer (i.e. no business logic) of EJBs (i.e. stateless session beans for remote access). Spring also provides support for proxying remote calls via RMI, JAX-RPC etc.

•Spring can facilitate good programming practice by encouraging programming to interfaces rather than to implementation.

•Spring provides a consistent framework for data access, whether using JDBC or O/R mapping frameworks like Hibernate, TopLink or JDO. Spring ORM support for hibernate reduces the code size by almost a half and provides additional benefits such as easier testing, consistent exception hierarchy (Spring folds your SQLException to a common set of unchecked exceptions) and management of Hibernate resources like SessionFactory. Spring exceptions are unchecked and hence you do not have to write any try{} catch{} and finally{} semantics and also you can manage the transactions declaratively via Spring transaction management (Refer Q43 in Enterprise section) using Spring AOP (Refer Q3 in Emerging Technologies/Frameworks section).

•Spring provides a consistent abstraction for transaction management by supporting different transaction APIs such as JTA, JDBC, Hibernate, iBATIS and JDO. Supports both programmatic transaction management and declarative transaction management (preferred approach for transaction management since it has least impact on application code due to its non-invasive nature). Unlike EJB, Spring does not have a default support for distributed transactions (i.e. XA transactions - ) but can plug-in a JTA transaction manager.

Q. What is the important consideration if you are using Spring declarative transaction management with EJB (i.e. for remote access)?

You need to turn off the EJB transaction support by setting the transaction attribute to “NotSupported”

<container-transaction > <method >

<ejb-name>CRMService</ejb-name> <method-name>*</method-name>

</method> <trans-attribute>NotSupported</trans-attribute>

</container-transaction>

•JDBC applications are verbose with try{}, catch{} and finally blocks and very tedious to write. A good abstraction layer like Spring lets you customize a default JDBC with a query and anonymous inner class (Refer Q35 in Java section ) to eliminate much of the code. You do not have to worry about managing the resources like DataSource, Connection, Statement and ResultSet, configuring your DataSource, managing transactions and SQLExceptions. Spring IoC + AOP (for declarative transaction) will take care of all these.

EJB 3.0 unlike EJB 1.x, 2.x does not have a home interface. The bean class may or may not implement a business interface. If the bean class does not implement any business interface, a business interface will be generated using the public methods. If only certain methods should be exposed in the business interface, all of those methods can be marked with @BusinessMethod annotation.

EJB 3.0 defines smart default values. For example by default all generated interfaces are local, but the @Remote annotation can be used to indicate that a remote interface should be generated.

The EJB 3.0 (i.e, Inversion Of Control design pattern) container takes care of the creation, pooling and destruction of the session bean instances and the application only works with the business interfaces. But if the application needs a finer control over the session beans, for example to perform database initialization when the container creates the session bean or close external connection etc, you can implement lifecycle callback methods in the bean class. These methods are called by the container at various stages(e.g. bean creation and destruction) of the bean’s lifecycle. Unlike EJB 2.1, where all callback methods must be implemented even if they are empty, EJB 3.0 beans can have any number of callback methods (i.e. even no methods at all) with any method name. In EJB 3.0, you can specify any

bean method as a callback by annotating it with the following annotations @PostConstruct, @PreDestroy, @PrePassivate, @PostPassivate, @PostActivate, @Init, @Remove (only for stateful session beans) and @PostConstruct.

public class AccountBean implements Account {

//...

@PostConstruct

public void initialize(){

//initialize data from the database

}

@PreDestroy

public void exit(){

//save data back to the database

}

}

An MDB (Message Driven Bean) class must implement the MessageListener interface.

EJB 3.0 makes use of dependency injection to make decoupled service objects and resources like queue factories, queues etc available to any POJO. Using the @EJB annotation, you can inject an EJB stub into any POJO managed by the EJB 3.0 container and using @Resource annotation you can inject any resource from the JNDI.

public class AccountMDB implements MessageListener {

@EJB Account account;

//use the “account” variable // … …

}

EJB 3.0 wires runtime services such as transaction management, security, logging, profiling etc to applications at runtime. Since those services are not directly related to application’s business logic they are not managed by the application itself. Instead, the services are transparently applied by the container utilizing AOP (Aspect Oriented Programming). To apply a transaction attribute to a POJO method using annotation:

public class Account {

@TransactionAttribute(TransactionAttributeType.REQUIRED) public getAccountDetails(){

//…

}

}

In EJB 3.0, you can extend the container services by writing your own interceptors using the @AroundInvoke annotation. You can specify any bean method as the interceptor method that will execute before and after any other bean method runs.

@Stateful

public class AccountBean implements Account {

//bean methods that are to be intercepted by the log() method

//… …

@AroundInvoke

public Object log(InvocationContext ctx) throws Exception { //…

}

}

EJB 3.0 supports both unidirectional and bidirectional relationships between entity beans. To create an entity bean, you only need to code a bean class and annotate it with appropriate metadata annotations. The bean class is a POJO.

@Entity

public class AccountEntityBean { private Integer accountNumber; private String accountName;

@id (generate=AUTO)

public Integer getUserId() { return this.accountNumber;

}

//getters & setters //… …

}

EJB QL queries can be defined through the @NamedQuery annotation. You can also create regular JDBC style queries using the EntityManager. POJOs are not persistent by birth and become persistent once it is associated with an EntityManager.

Q.What recent technology trends are vital to enterprise Web development?

•Component based Web frameworks like JSF and Tapestry.

•Ajax (Asynchronous JavaScript and XML).

Q.What is a component based and event-driven Web framewok? How do they differ from request based frameworks like Struts?

Struts and many other MVC Web frameworks are request based and to achieve reusability you typically develop JSP tag libraries and/or include files with common functionality. This approach of reusability is not only ugly but also difficult to achieve code reuse. Component based and event-driven Web frameworks have emerged to provide better code reuse and improve ease of development. These component based frameworks provide an API for developing reusable features that are easily packaged and reused across applications. These frameworks are very useful when developing large Web applications or many Web applications with common functionality. The leading contenders in this space of component based and event-driven frameworks are JavaServer Faces (JSF) and Tapestry. These frameworks

•bury the Servlet API deep down and shield the developer from having to work directly with the Servlet API.

•bind Web display controls directly to Java object properties and user interactions like button click etc are mapped directly Java event handling methods in these Java objects (just like Swing).

•allow you to group and package chunks of functionality into components to be reused in different contexts or applications. The standard framework ships with the core components, enabling the most commonly required functionality and you can make use of these components to build more reusable components more specific to your application or industry.

Both the JSF and Tapestry address the above mentioned fundamentals but they differ greatly the way they implement these fundamentals.

Q 19: Briefly explain key features of the JavaServer Faces (JSF) framework?

A 19: JavaServer Faces is a new framework for building Web applications using Java. JSF provides you with the following main features: