34. Difference between Hibernate, EJB and JDBC

EJB 2.X	EJB 3.X	Hibernate	JDBC
PROS Security is provided for free for accessing the EJB. Provides declarative transactions. EJBs are pooled and cached. EJB life cycles are managed by the container. Has remote access capabilities and can be clustered for scalability.	PROS A lot less artifacts than EJB 2. x. Make use of annotations or attributes based programming. Narrows the gap between EJB 2. x and O/R mapping. Do support OO concepts like inheritance.	PROS Simple to write CRUD (create, retrieve, update, delete) operations. No container or application server is required and can be plugged into an existing container. Tools are available to simplify mapping relational data to objects and quick to develop.	PROS You have complete control over the persistence because this is the building blocks of nearly all other persistence technologies in Java. Can call Stored Procedures. Can manipulate relatively large data sets.
CONS Need to understand the intricacies like rolling back a transaction, granularity etc, infrastructures like session facades, business delegates, value objects etc and strategies like lazy loading, dirty marker etc. EJBs use lots of resources and have lots of artifacts. Does not support OO concepts like inheritance.	CONS Since it is new, might be too early to use in commercial projects. It is still evolving.	CONS Little or no capabilities for remote access and distributability. Mapping schemas can be tedious and O/R mapping has its tricks like using lazy initialization, eager loading etc. What works for one may not work for another. Limited clustering capabilities. Large data sets can still cause memory issues. Support for security at a database level only and no support for role based security without any add on APIs like Aspect Oriented Programming etc.	CONS You will have to write a lot of code to perform a little. Easy to make mistakes in properly managing connections and can cause out of cursors issues. Harder to maintain because changes in schemas can cause lot of changes to your code. Records need to be locked manually (e.g. select for update).
As a rule of thumb, suitable for distributed and clustered applications, which is heavily transaction based. Records in use say between 1 and 50.	As a rule of thumb, suitable for distributed and clustered applications, which is heavily transaction based. Records in use say between 1 and 100.	Suitable for records in use between 100 and 5000. Watch out for memory issues, when using large data sets.	Where possible stay away from using JDBC unless you have compelling reason to use it for batch jobs where large amount of data need to be transferred, records in use greater than 5000, required to use Stored Procedures etc.