Oracle Portal is a browser based, self-service, content publishing and development solution that allows end users and web developers to build data driven web sites. Portal gives content creators the tools needed to publish their own documents on the Web, by directly editing Web site from within their Web browsers.

About Portals

Portals offer many advantages over other software applications. First, they provide a single point of entry for employees, partners, and customers. Second, portals can access Web services transparently from any device in virtually any location. Third, portals are highly flexible; they can exist in the form of B2E intra-nets, B2B extra-nets, or B2C inter-nets. Fourth, portals can be combined to form a portal network that can span a companys entire enterprise system, allowing for access both inside and outside the firewall.

Portals have many advantages, which is why they have become the de facto standard for Web application delivery. In fact, analysts have predicted that portals will become the next generation for the desktop environment.

Portals distinguish themselves from other software systems because they provide the ability to integrate disparate systems and leverage the functionality provided by those systems. As such, they are not mutually exclusive, and do not force you into an either-or decision vis-a-vis existing software systems. This point is of paramount importance, particularly when you consider the fact that Web services are destined to fuel the explosion of Web applications. Since portals can access any Web services, the conclusion is inescapable: portals provide a unique opportunity to leverage the functionality of nascent technologies as well as mature, well-established software systems.

Portal also lets you decentralized content management, while maintaining centralized control of your Internet infrastructure.

Oracle originally heavily touted the development capabilities of Portal, but it is cumbersome to develop anything other than the default generated forms and reports in Portal. Other products like Oracle Reports must be used along with Portal to generate much meaningful content. The management capabilities of Portal are strong however and are tied directly to the Oracle database. If you are already an Oracle shop Portal should be considered seriously as a portal framework. Given Oracle’s dominance in the marketplace the product will certainly be very prominent.

Oracle Portal is part of Oracle iAS (Intenet Application Server). Portal was build on top of Oracle PL/SQL. Consider Plumtree as a possible alternative.

Some Product Features:

Integrated web publishing services for content publishing and data publishing.
An intuitive portal framework for organizing, structuring, and customizing corporate information.
A central environment for portal deployment, management, monitoring, and maintenance.
Available in other languages like French, German, Dutch, Spanish, Italian, French and Danish.
Compatible with Oracle database (versions 7.3.4, 8.0.5, and 8i).

What is the difference between a portal and a portlet?

A portal is a web site that acts as hub, gateway or window to other information and services on the Web. Common Web portals are Yahoo, Netscape, etc.

A portlet is a specialised content area that occupies a small window of a portal page. Portlets from different sources (Portlet Providers) can be integrated into the portal framework. Example portlets: weather info, news flashes, stock tickers, etc.

What is Oracle-Portal-to-Go and what is it used for?

Oracle Portal-to-Go provides wireless services to mobile devices. It ships as part of the Oracle iAS (internet Application Server) Wireless Edition product.

Portal-to-Go dynamically translates existing Web content into XML, and then parses out that XML content into the format required by the mobile device; such as WML for WAP compliant devices, or “tiny” HTML for Palm devices. Additional output mark-up language capabilities include HDML, TTML, Pager-text and VoxML (for IVR systems).

How does one create a new Portlet?

Oracle provides a set of PL/SQL procedures to create new portlets.

Please ensure that the following is done wherever necessary:

1. always make sure that an empty space follows all the following punctuation marks: (only 1 empty space by pressing the space bar)
! % & ) - = ] } ” ‘ : : > . , ?

2. for hyphenated words, please ensure there is no space before and after the hypen.
e.g. stop-gap, co-traveller, co-worker etc.

3. all short forms (abbreviations) should be followed by a full stop and a space.
eg. abbrev.
vs.
etc.
Mr.
Ms.

4. please do not abuse the existence of the apostrophe ( ‘ ). an apostrophe is used only for possessive - when something belong to someone or something.
eg.
David’s dog - this means the dog belonging to David
video’s list - this means the list that belong to the video section

for Plurals and for words/names that end with ‘S’ there need not be an apostrophe followed by an ‘S’, just apostrophe will do.
eg. Players’ jerseys, Demarcus’ shot - not Players’s jerseys or Demarcasus’s shot

5. please DO NOT use the apostrophe for plurals.
eg.
The dogs went running in the park - this means many dogs ran in the park (it should not be “The dog’s went running…” - this is incorrect)
The list of videos is not populated - this means that the list of videos (not video’s) is not populated. (it should not be “The list of video’s is not populated” - this is incorrect)

For some words like Sheep, data, information, news, furniture, the singular and plural are the same.

Check the words below to to find their plural.

Shot on Goal Shots on Goal
List Lists
Survey Surveys
Axis Axes

6. Please use the articles (a, an and the) also properly.
a will be used for all nouns/adjectives starting with a consonant. it should be a singular word.
eg. a dog, a noisy cat - not an dog or an noisy cat

an will be used for nouns/adjectives starting with a vowel. it should be a singular word.
eg. an ache, an ardent follower - not a ache or a ardent follower

the will be used for a definite word (either starting with a vowel or a consonant). it could be a singular or plural word.
eg. the Earth, the skies etc.

exceptions:
an will also be used wherever the word starts with a consonant, but is mute, giving place for the vowel (in the second letter) to be pronounced. it should be a singular word.
eg. an honourable intention, an honest worker - not a honourable or a honest

a will be sued for some words which start with a vowel but are pronounced without the vowel’s phonetic sound but actual sound - don’t know if I made much sense here. it should be a singular word.
eg. a university, a universe, a one rupee coin - not an university or an universe or an one rupee coin (if you notice the way ‘u’ is pronounced here is different to the ‘u’ in ‘umbrella’, ‘understanding’ etc. and the way ‘o’ is pronounced in ‘one’ in comparison to ‘o’ in ‘other’, ‘outsider’ etc.)

7. Capital Letters have to be used at the beginning of all sentences. You know when a sentence begins when: 1. it is the forst sentence of a paragraph or 2) it will be preceeded by a full stop from the end of the sentence before it.

Captial Letters should also be used for Proper Nouns (names, places, titles etc.)
eg. Anand, Chennai, Earth, Monday, December.

Here are some points that will definitely help.

1) The font of mail should be Verdana and font size should be 9.5 or 10.
2) The mail should have a Pyramid Structure i.e. it should contain:
* Situation: What’s the current situation is
* Action items: What you expect from the reader of the mail to-do
* Information: The information you want to give to the reader
* Conclusion: Conclude with a Thank You.
3) For writing use only Black or Blue color. For highlighting purpose make the word
bold. Avoid using Red color as Red signifies danger, so use it when urgent.
4) For greetings in mail:
* For Americans: use Hi
* For Europeans: use Hello
* For Asians: use Dear
To be more formal we could use Dear Mr. /Ms. followed by Last name or Full name.
We should not use Dear Mr. /Ms. followed by First name alone.
5) We should not put ‘/’ in greetings like Hi X/Y. Instead we should say Hi X and Y.
6) We should not use ‘Thanks and Regards’. Instead we should say:
Thank you
Regards

7) For requesting something we should not use Can, instead we should use Could. We should not write ‘Please find the attached file’ because the reader does not
have to find or search for the file in the mail it’s already there. So instead we should
write
‘The file has been attached for your reference’.
9) We should not use sentences like ‘As per your mail’ because ‘per’ is used only with
units like per Kg etc. Instead we should write ‘According to your mail’.
10) We should use parallel structure. Parallelism enables readers to read documents
more efficiently. For e.g. The analysis will include planning, organizing, dividing and
assessment
(Instead assessment we should write Assessing) of turnaround functions.
11) In our mails we often write ‘Please revert back’. Instead we should only write
‘Please revert’.
12) For the Signature in mail, if we are sending to people in our company only then
we should not write our company name in the signature because they already know
that we are part of the same company but if we are sending mail to an external
party like client etc then we should write our company name in the signature
because there we have to brand our company name in front of others.

Today,more and more companies want to develop distributed transactional applications for the enterprise and leverage the speed,security,and reliability of server-side technology. Before presenting a way of designing such a system,several key terms need to be understood.

What is J2EE?

The Java 2 Platform Enterprise Edition (J2EE) technology provides a component-based approach to the design,development,assembly,and deployment of enterprise applications. The J2EE platform provides the ability to reuse components in different applications. J2EE is made up of 13 different technologies including JavaServer Pages,Servlets,Enterprise JavaBeans,JavaMail,XML,JavaMail and many more.

The main technologies that we will be using are:
• JavaServer Pages (JSP).
• Servlets
• EJB

What are JavaServer Pages?

JavaServer Pages (JSP) is a technology based on the Java language and enables the development of dynamic web sites. JSP was developed by Sun Microsystems to allow server side development. JSP files are HTML files with special Tags containing Java source code that provide the dynamic content.

What are Servlets?

A Servlet is a Java class that provides special server side service. To display any information on a web page,HTML code is embedded in “println” statements. JSP technology is an extension of Servlets. It is easier to generate GUI pages using JSP because a web page editor (such as Macromedia DreamWeaver ) can be used to create simple pages.

What are Enterprise JavaBeans?

Enterprise JavaBeans (EJB) provides a component specification for the development of scalable and secure middleware components. The EJB Server handles security and transaction management details so developers can focus on implementing the business logic.

What are the benefits of using J2EE?

There are several reasons for using the J2EE set of technologies:

Extensibility and maintainability
Division of work along skill lines
Scalability,portability,availability.
Code reuse.
Interoperability – legacy integration
Focus on implementing business logic
Separation of code with differing rates of change.

Simple J2EE application

In our simple J2EE application,the customer visits a web page (JSP). The request is sent to the web server then passed to the JSP and Servlet engine. The JSP code is executed including a search on the database. The database results are returned to the JSP page. The JSP page dynamically generates a HTML page with the data and sends it to the Customer.

Advantages.
• Simple of understand and initially develop.

Disadvantages.
• The JSP page is very difficult to maintain. It contains HTML and Java code with queries to the database. The business logic should not be in the JSP; otherwise many pages will need to be changed every time business requirements change.
• Need to have data connectivity code in every JSP page.
• Does not scale up very well.
• Security issues - If a hacker gained access to the web server,all the confidential business logic can be read by opening the JSP files.

The following diagram shows the architecture of a typical J2EE application. This is similar to the previous example,except all business logic is contained in different EJB components.

The diagram below shows how the JSP connects to the EJB object,which queries the database. This was the JSP does not contain the database queries and some business logic has been moved into the EJB layer. The EJB container is designed to create copies (instances) of the EJB class as required in memory. This enables it to scale up as multiple requests come in.

Advantages.

More secure because all the business logic is stored in the EJB components. An EJB component can be configured so only a specific user in a group can be given access to a limited set of methods.

By adding more EJB Application Servers,the system can easily scale up. However,you need to make sure the EJB components have been designed and deployed correctly.

Transaction Management support - Transaction attributes are specified on an application component during assembly. This lets you group methods into transactions across application components,which means you can easily change application components within a J2EE application and reassign the transaction attributes without changing code and recompiling.

Disadvantages.

All the JSP pages need to include code that locates the EJB components.

There is still quite a bit of functionality in the JSP files.

The current architecture does not support reuse at the JSP level so all the code will need to be replicated. This will cause major maintenance problems.

The JSP pages are still too complex for web designers to use.

Layered Approach.

The actual architecture of the application has been separated out into several layers.

1. Presentation view
2. Presentation logic
3. Business logic
4. Data Model

1. Presentation view.

This is the actual look,feel and presentation of the application. In J2EE,Java Server Pages (JSP) are used to implement your view.

2. Presentation Logic

This is the code required to call business logic and return output to the view. Java Servlets / java beans are the best way to implement presentation logic.

3. Business Logic

This is code required to execute the usecase actions and manipulate the data model. EJB Session beans are the containers of the business logic for all your usecases.

4. Data Model

J2EE provides a useful abstraction for your data model,called EJB Entity beans. These are persistent objects that model your real world business abstractions.

The layered approach has the following benefits:

• Encapsulation – each layer hides details from the other layers. Therefore a layer can change without affecting other layers.
• Separation - Complexity in the system is easier to manage because each layer is focused on a cohesive set of responsibilities.
• Reuse – each layer can provide services to the layer above,so classes can be reused whilst still abstracting the implementation details.

This leads to applications that are more flexible and maintainable.

This section details the structure and functionality of the Hibernate XML Configuration File and the Hibernate Mapping Files.

Hibernate Configuration File

An application that uses Hibernate API must use a single configuration file. A configuration file for a Hibernate application will tell some of the information like the URL of the Database Server to which the application wants to connect, the username/password for the Database, class name of the Driver file and with other set of preferences.

A Hibernate configuration file can be an XML-based file (hibernate.cfg.xml) or it can be ordinary Java properties file (hibernate.properties) with key-value combination. This configuration file should be placed in the run-time classpath of an application. If both the XML-based configuration file and the properties-based configuration file are found in the classpath, then the XML-based configuration file will take preference over the other.

Following is the structure of a Hibernate configuration file,

Hibernate.cfg.xml:

Let us look into the structure of the XML in detail here. The first observable thing is that this XML has a well-defined DTD defined from “http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd” meaning that the construction of this XML document should be validated against the DTD.

The outer-most element is the ‘hibernate-configuration’ element which forms the root element for specifying the configuration information. The next inner element is the ’session-factory’ element which corresponds to the SessionFactory class that contains information related to the Database like the URL of the Database server, the username/password information on the Database server etc.

The various properties within the ’session-factory’ element is represented in Hibernate Configuration file as a ‘property’ element.

Whenever we say,Configuration configuration = new Configuration().configure(), the no argument Configuration.configure() method will load the configuration file called “hibernate.cfg.xml” from the application’s classpath. The default name for the Hibernate Configuration file is “hibernate.cfg.xml”. Different configuration file can be loaded into the application by calling the one-argument Configuration.configure() method, like the following,

File configurationFile = new File(”.\\config\\MyConfiguration.xml”);
Configuration configuration = new Configuration().configure(configurationFile);

The code, SessionFactory sessionFactory = configuration.buildSessionFactory(), will populate the SessionFactory object with the set of property values values that are taken from the ’session-factory’ XML element. So, in our case, the SessionFactory object will be populated with values the class name of the driver, the URL of the Database server and the username/password of the Database.

The next section in the Hibernate Configuration File is the ‘mapping’ element which represents a XML file that contains the mapping information such as how a Java Class should be mapped against a Database table. The next section deals with the structure of the Mapping Files in greater detail.

The same configuration information in the XML-based Hibernate configuration file can be given in the property-based Hibernate configuration file and such a file may look like the following,
hibernate.properties:

hibernate.connection.driver_class = ClassNameOfTheDriver
hibernate.connection.url = URLOfTheDatabaseServer
hibernate.connection.username = DatabaseUsername
hibernate.connection.password = DatabasePassword

Hibernate Mapping Files

A Hibernate mapping file provides mapping information like how a Java Class is mapped to a relational database table. It also contains other information like which Java Property (or Field) in a class will map to which Table Column. Relations between entities can be defined in the Mapping file through various associations like one-to-one, one-to-many, many-to-many etc.

The mapping files that are needed for an application are defined and referenced in the Hibernate configuration file throught the ‘mapping’ element. If you remember, the Hibernate configuration file has references to Hibernate mapping files like this,

Let us look into the structure of a mapping file.
TestMapping.xml:

Like the Hibernate Configuration file, this mapping file has to be validated against the DTD given by “http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd”. The root element in this XML file is the ‘hibernate-mapping’ which acts as a container for several different mapping definitions in the form of ‘class’ tag. Any number of mapping definitions can be given inside the ‘hibernate-mapping’ element, but the preferred way is to give one definition per XML file.

The ‘name’ attribute in the ‘class’ element is the name of the Java class that we want to persist. The ‘table’ attribute represents the name of the table for this java Class in the database. All the ‘property’ elements will map Java fields to Table Column names. The Java Field is identified by the ‘name’ attribute in the ‘property’ element and the table column name is represented by the ‘name’ attribute in the ‘column’ element.

A primary key is a must for every table as it used to uniquely identify Java instances. The ‘id’ element represents the primary-key portion wherein with ‘name’ and the ‘column’ attribute corresponds to the Java Field and the table primary key column. The value for the ‘generator’ element represents how the primary-key is generated for the table. So many different implementations for generating a primary-key are available in Hibernate like ‘identity’, ’select’, ‘assigned’, etc. If the value of the ‘generator’ element is ‘assigned’, then it is the responsibility of the developer to manually set the primary key.

Hibernate Configuration file:

Following is the Hibernate configuration file.

hibernate.cfg.xml:

The above XML file has the various database parameters like the URL, class name of the driver, username and password set to ‘jdbc:mysql://localhost/DbForHibernate’, ‘com.mysql.jdbc.Driver’, ‘root’ and ‘root’ respectively. We have already seen how these various parameters will affect the configuration of the SessionFactory object.
Sql Dialects:

The only new property defined in this file is the ‘dialect’ property which is pointing to org.hibernate.dialect.MySQLDialect. Dialects are one among the various new features in Hibernate. Consider a database vendor ‘DB-V1′ who provides a feature called performance tuning using some SQL syntax. If some other database vendor ‘DB-V2′ provides that performance tuning feature, then it’s very likely that the syntax of both the queries will be different.

Suppose, if such a feature is enabled in a hibernate application by some piece of code, Hibernate should using two different syntax for two different databases. How will Hibernate knows the correct SQL syntax for different databases?

The answer lies in SQL Dialect. Every database has their own SQL Dialect. The following provides some major SQL Dialects from some popular Database vendors.

Database SQL Dialect

Microsoft SQL Server org.hibernate.dialect.SQLServerDialect
MySQL org.hibernate.dialect.MySQLDialect
Oracle org.hibernate.dialect.OracleDialect
Informix org.hibernate.dialect.InformixDialect
Sybase org.hibernate.dialect.SybaseDialect

So, if an application uses any vendor specific features, it is a must that the application must provide that particular SQL Dialect in the Hibernate Configuration file to function properly.
Hibernate Mapping File: The XML-based Hibernate mapping file is shown below,

As explained previously, the Hibernate mapping file contains the mapping information between a Java Class and the database table name. In the above file, the value for the ‘generator’ element is given as ‘assigned’, which means that the application when persisting the Java object must manually set the value for the primary key (in our case, it’s the ‘Id’ column). If it is not set, then an exception will be thrown by Hibernate at run-time.
Client Application:

Following is the listing for the Client Application.
RunClient.java:

package client;

session.close();
}catch(Exception e){
e.printStackTrace();
}
}
}

For the above program to compile and run properly, two set of Jar files have to placed properly in the application’s class-path. One is the set of Jar files that are available within the Hibernate Ditribution, which is normally the \lib, where refers to the installation of the Hibernate. Following jar files from the Hibernate distribution have to be maintained in the class-path of the application,

* cglib2.jar
* commons-collections
* commons-Logging
* dom4j.jar
* ehcache.jar
* jdbc2.0-stdext
* jta.jar
* log4j.jar
* odmg.jar
* xalan.jar
* xerces.jar
* xml-apis.jar

The other set of the jar files are for the Jdbc Driver, which is ‘mysql-connector-java-5.0.5-bin.jar’ in the case of MySQL Database.

The above code establishes a Configuration object by calling new Configuration().configure() which scans the classpath for the presence of hibernate.cfg.xml file. It then creates an instance of SessionFactory object with the details populated from the Configuration File by calling Configuration.buildSessionFactory(). A new Session object is then created for persisting objects by calling SessionFactory.openSession().

A new Java object called ‘User’ is populated with some test values and the object is persisted into the Session object within a transactional context by calling Session.beginTransaction() which marks the beginning of the transaction. Remember that Session.save(object) only marks the object to be persisted. After a successful save operation and transaction is committed by calling Transaction.commit(), which means that the object will be synchronized with the database.

Before the advent of Hibernate, there were so many other technologies and specifications from Sun, for persistence. Few are them are explained in detail in the following sections along with their drawbacks which led them not being able to become a successful one.

Problems with JDBC

Java provided an initial solution for persistence in the form of JDBC and developers are depending on JDBC API’s to connect to the database. One of the major drawbacks of JDBC is that, one has to embed the application’s data into the SQL syntax, i.e., for saving the data in an application, the business object has to be converted to relational-object model by embedding the various pieces of data within the SQL language syntax.

Consider the following situation, there is a business object called Employee with properties name and age and this has to be persisted to a database. The following is the class representation of the Employee class,

class Employee
{
private String name;
private int age;

//Other Methods go here.

}

Employee employee = getEmployeeObject();
String sqlInsertStmt = “INSERT INTO EMPLOYEE VALUES (’” + employee.getName() + “‘, ‘” +
employee.getAge() + “‘)”);
statement.executeQuery(sqlInsertStmt);

The above is generally a poorer code, and also the business object (Employee object, in our case) is tightly integrated with the SQL syntax.

During data retrieval, the reverse of the above process will happen. The information that is fetched from the database has to be mapped to the business object. Consider the following piece of code which has the conversion process of representing the business object from the relational data model.

String sqlQueryStmt = “SELECT * FROM EMPLOYEE WHERE EMP_ID = ‘100′”);
ResultSet employees = statement.executeQuery(sqlInsertStmt);

if (employees.next())
{
Employee fetchedEmployee = new Employee();
fetchedEmployee.setName(employees.getString(”name”));
fetchedEmployee.setAge(employees.getInt(”age”));
}

Entity Beans

Entity beans, which were one of the major components in the EJB Specification failed drastically to provide a persistent layer in the applications.

The initial version of the EJB specification has little support for the Entity beans. The first disadvantage is, an Entity Bean is not a local object, but a remote object, so, there are overheads related to network performance issues. And the worst thing is that the relationships between entity beans have to be manually managed in the application code and the actual mappings were done in vendor-specific configuration files which invented lots of changes in the configuration files when the application is made to point out to a different database server.

Though, the later version of the specification overcome many of the drawbacks that were found in the initial versions by introducing the notion of local interfaces for representing an enterprise bean and EJB Query Language (EJB-QL), etc., the art of designing and managing an entity bean still yielded much complexity in the hands of the developers.

Hibernate - ORM product

Hibernate is one of the Object-Relational Mapping software for persisting and querying data. Most of the Hibernate features look very similar that are found in “Java Persistence API (JPA)” specification. Also Hibernate provides some add-on functionalities that are not mentioned in the JPA specification. Hibernate doesn’t replace JDBC. Hibernate is sitting on top of JDBC to connect to the database. Internally Hibernate is using these JDBC calls to connect to the database systems.

Hibernate is neither forcing its developers to use some specific interfaces for the classes to be persisted in an application nor it requires the program to follow some standard design to achieve its goals. For this reason, Hibernate can well integrate with all kinds any of J2SE/J2EE application and with any kind of frameworks (like Spring, Struts etc).

Hibernate Modules

The open-source Hibernate project has various different modules each representing a unique functionality.

* Hibernate Core which represent the basic and the core module of the Hibernate project provides support for OO features along with the Query services.
* Another module called Java Persistence with Hibernate is an implementation for the specification “Java Persistence API (JPA)” from Sun and we can be used in any Sun’s compliant Application Server as well as with J2SE applications.
* There is a separate module called Hibernate Search that provides rich functionality for searching the persistence domain model using a simplified API.
* For validating the data, Hibernate comes with a set of validation rules in the form of Annotations in a module called Hibernate validations and it also allows the developers to create custom validation rules.
* Support for Querying and inserting data from multiple databases can be achieved by using the Hibernate Shards API.

Hibernate Core API

Following section covers the various core interfaces/classes that should be used by an application which is depending on the persistence-level service from Hibernate.

The ‘Configuration’ class

The Configuration class is the initial entry point of a Hibernate application. An instance of Configuration class represents application specific configuration that provides persistence services. This class provides convinient ways to import the Hibernate Configuration File and the necessary Mapping Files (which are discussed later) into an application which can be later used by SessionFactory (which is detailed in the next section) class to create Session objects.

The following code shows how to create and configure a Configuration object.

Configuration configuration = new Configuration().configure();

Calling the Configuration.configure() method will configure the object by loading the configuration file and the mapping files that are available in the application’s class-path.

Usually only one instance of a Configuration class will be maintained by an application.

The ‘SessionFactory’ interface

The Configuration class can be used to create SessionFactory object which serves as a factory class that creates Session objects (discussed in the next section). An application may have one SessionFactory class but many number of Session objects. The following code shows how to create a SessionFactory object by calling the Configuration.buildSessionFactory().

Configuration configuration = new Configuration().configure();
SessionFactory sessionFactory = configuration.buildSessionFactory();

Configuration.buildSessionFactory() will create a new SessionFactory object with configurations and the mapping information taken from the Hibernate Configuration and the Mapping Files.

The ‘Session’ interface

A Hibernate Session interface forms the primary interface for promoting persistence services to the application classes. The following code shows how to create a Session object.

Configuration configuration = new Configuration().configure();
SessionFactory sessionFactory = configuration.buildSessionFactory();
Session newSession = sessionFactory.openSession();

Calling the SessionFactory.openSession() method, will create a new database connection (the connection related information like the Database server, username, password etc., will be taken the Hibernate configuration files which is discussed in the later section) and opens a new session from the created connection. Calling the SessionFactory.openSession() method again will create new Session objects as well as new java.sql.Connection object. One can get a reference to the newly created connection by calling the Session.connection() method, like the following,

java.sql.Connection connection = session.connection();

Object Classification based on States

Three different types of objects are categorized in Hibernate technology based on the state of the object. They are,

# Persistent Object
# Transient Object
# Detached Object

Persistent Object:

A persistent object is one which is associated with the current Session and has its state values synchronized with the database.

Transient Object:

A transient object doesn’t have any association with the current Session, but can be made persistent at a later time.

Detached Object:

A detached object was having an association at a previous point of time with the Session interface, but now is made to detach (taken-off) from the current Session.

Operations using the Session Interface

As seen previously, the Session interface provides various services in the form of operations for persisting any Object. It also provides transactional services to the persistent objects. Rich Querying operations are also supported in the form of Query interface. The following code can be used to persist an object.

Employee objectToBePersisted = new Employee();
// Set properties for employee object here.
Session session = …;
session.save(objectToBePersisted);

Session.save(object) can be used to save a persistent object along with a unique key (primary key). Calling the method again on the same object will cause the following exception to be thrown. org.hibernate.exception.ConstraintViolationException. However, calling this method doesn’t immediately synchronize the state of the object with the database. It will just mark this object to be saved. Calling the method Session.flush() will make all the objects that are associated with the Session to be synchronized with the database.

session.flush();

There is a method called Session.update(object) which is used to update the state of the persistent object that was modified for some reasons after a call to Session.save(object). Consider the following code which will demonstrate this,

Employee employee = …;
//Set employee properties here.
session.save(employee);

//Update the properties of employee object here.
employee.set(…);
session.update(employee);

If you don’t like to use Session.save(object) or Session.update(object), use the smart Session.saveOrUpdate(object) method, which will call Session.save(object), if the object in consideration is a new object or will call Session.update(object), if it is an updated (saved) object.

session.saveOrUpdate(employee);

There are so many other useful services and operations available from Session interface like Session.delete(object), Session.merge(object), and Session.refresh(object).

Objects can be retrieved from the Database using the Query interface. The following code resembles the traditional select query to select all the object from a table called User.

Query selectQuery = session.createQuery(”FROM User”);
List userList = selectQuery.list();
for(int index = 0; index < userList.size(); index ++){
User user = (User)userList.get(0);
System.out.println(”Name = ” + user.getName() + “, Age = ” + user.getAge());
}