• +91 9971497814
  • info@interviewmaterial.com

Hibernate Interview Questions Answers

Question 1 :  What are the benefits of detached objects?

Answer 1 : Detached objects can be passed across layers all the way up to the presentation layer without having to use any DTOs (Data Transfer Objects). You can later on re-attach the detached objects to another session.

Question 2 :  What are the pros and cons of detached objects?

Answer 2 : Pros: " When long transactions are required due to user think-time, it is the best practice to break the long transaction up into two or more transactions. You can use detached objects from the first transaction to carry data all the way up to the presentation layer. These detached objects get modified outside a transaction and later on re-attached to a new transaction via another session. Cons " In general, working with detached objects is quite cumbersome, and better to not clutter up the session with them if possible. It is better to discard them and re-fetch them on subsequent requests. This approach is not only more portable but also more efficient because - the objects hang around in Hibernate's cache anyway. " Also from pure rich domain driven design perspective it is recommended to use DTOs (DataTransferObjects) and DOs (DomainObjects) to maintain the separation between Service and UI tiers.

Question 3 : Are collections pageable?

Answer 3 : Query q = s.createFilter( collection, "" ); // the trivial filterq.setMaxResults(PAGE_SIZE);q.setFirstResult(PAGE_SIZE * pageNumber);List page = q.list();

Question 4 : Can I map an inner class?

Answer 4 : You may persist any static inner class. You should specify the class name using the standard form ie. eg.Foo$Bar

Question 5 : Does Hibernate implement its functionality using a minimal number of database queries?

Answer 5 : Hibernate can make certain optimizations all the time: Caching objects. The session is a transaction-level cache of persistent objects. You may also enable a JVM-level/cluster cache to memory and/or local disk. Executing SQL statements later, when needed. The session never issues an INSERT or UPDATE until it is actually needed. So if an exception occurs and you need to abort the transaction, some statements will never actually be issued. Furthermore, this keeps lock times in the database as short as possible (from the late UPDATE to the transaction end). Never updating unmodified objects. It is very common in hand-coded JDBC to see the persistent state of an object updated, just in case it changed.....for example, the user pressed the save button but may not have edited any fields. Hibernate always knows if an object's state actually changed, as long as you are inside the same (possibly very long) unit of work. Efficient Collection Handling. Likewise, Hibernate only ever inserts/updates/deletes collection rows that actually changed. Rolling two updates into one. As a corollary to (1) and (3), Hibernate can roll two seemingly unrelated updates of the same object into one UPDATE statement. Updating only the modified columns. Hibernate knows exactly which columns need updating and, if you choose, will update only those columns. Outer join fetching. Hibernate implements a very efficient outer-join fetching algorithm! In addition, you can use subselect and batch pre-fetch optimizations. Lazy collection initialization. Lazy object initialization. Hibernate can use runtime-generated proxies (CGLIB) or interception injected through bytecode instrumentation at build-time. A few more (optional) features of Hibernate that your handcoded JDBC may or may not currently benefit from second-level caching of arbitrary query results, from HQL, Criteria, and even native SQL queries efficient PreparedStatement caching (Hibernate always uses PreparedStatement for calls to the database) JDBC 2 style batch updates Pluggable connection pooling Hopefully you will agree that Hibernate approaches the parsimony of the best hand-coded JDBC object persistence. As a subscript I would add that I have rarely seen JDBC code that approaches the efficiency of the "best possible" code. By co

Question 6 : Hibernate uses so much runtime reflection?

Answer 6 : Many former C or C++ programmers prefer generated-code solutions to runtime reflection. This is usually justified by reference to the performance red-herring. However, modern JVMs implement reflection extremely efficiently and the overhead is minimal compared to the cost of disk access or IPC. Developers from other traditions (eg. Smalltalk) have always relied upon reflection to do things that C/C++ needs code-generation for. In the very latest versions of Hibernate, "reflection" is optimised via the CGLIB runtime bytecode generation library. This means that "reflected" property get / set calls no longer carry the overhead of the Java reflection API and are actually just normal method calls. This results in a (very) small performance gain.

Question 7 : How can I assign a default value to a property when the database column is null?

Answer 7 : Use a UserType.

Question 8 : How can I bind a dynamic list of values into an in query expression?

Answer 8 : Query q = s.createQuery("from foo in class Foo where foo.id in (:id_list)");q.setParameterList("id_list", fooIdList);List foos = q.list();

Question 9 : How can I convert the type of a property to/from the database column type?

Answer 9 : Use a UserType.

Question 10 : How can I create an association to an entity without fetching that entity from the database (if I know the identifier)?

Answer 10 : If the entity is proxyable (lazy="true"), simply use load(). The following code does not result in any SELECT statement: Item itemProxy = (Item) session.load(Item.class, itemId);Bid bid = new Bid(user, amount, itemProxy);session.save(bid);

Hibernate Contributors


Share your email for latest updates


Our partners