The main aim of is HUMAN RESOURCE MANAGEMENT SYSTEM is automating the resume processing for organization that is applied by the candidates. With this project organization can add the resume to the database and track the resumed to various rounds and it provides reports on jobs. The objective is to develop customize software package for organization.
The Human Resource Management System is developed using ORACLE as back-end and HTML, JSP as front-end. The operating system being used is the Windows 2000 prof.
The automation of the above mentioned system reduces human dependences and avoids errors in data storage, analysis and retrieval. The time taken for searching candidate details is also drastically reduced due to the automation process, thus reducing the whole cycle time.
This project performs three major roles:
Human Resource Management System is accessible to the HR Department of the organization “GIT Solutions ”. The functional scope of the system is to provide the user friendly environment in the process of recruitment and it provides search based on particular search criteria to update resume and so scheduled and up to interview rounds. It provides reports based on job positions search.
The main objectives of the Human Resource Management System are as follows:
It provides security to the application through login check of the user of this system through this web-based application maintenance of the recruitment process is being done in less time and add efficient manner. The module will be built using Oracle and html and jsp to allow for future enhancement and additions.
Applicant: An Individuals that is looking for career GIT Solutions
Interview: A meeting between any Executive of GIT Solutions and applicants,
where GIT Solutions determines if the employee’s skill set matches
the job that they are trying to fill.
Resume: A document containing the applicant’s Personal details, job details
Education, Skills, Past Employment, Reference information.
Test: An exercise to measure quantitatively the aptitude for specified job
Posting: Feeding of information of applicant into Application or storing of
application into the database.
HRMS: Human Resource Management System
JSP: Java Server Page
JDBC: Java Data Base Connectivity
ODBC: Oracle Data Base Connectivity.
HTML: Hyper Text Markup Language
HTTP: Hyper Text Transper
The main aim of is HUMAN RESOURCE MANAGEMENT SYSTEM is automating the resume processing for organization that is applied by the candidates. With this project organization can add the resume to the database and track the resumed to various rounds and it provides reports on jobs. The objective is to develop customize software package for organization.
No proper dynamic search method is available to immediately access a particular record. Fast retrieval of required data is not possible thus causing delay and unnecessary search of the entire list.
FoxPro under Novel NetWare version is not a graphical user interface based application. User interaction with the system is minimized because of the DOS environment, unlike the windows environment where the user interaction with the system is high.
Keeping in view of growth that has been envisaged, it may not be practical and economical to continue with the current system. To facilitate a more efficient Recruitment System and to increase the responsiveness, it is necessary to have better Recruitment System integrated with the enterprises Information System.
Proposed system is Computerized Recruitment Processing System. A Computer based system is usually needed for the following purposes:
Greater processing speed:
Using computers inherent ability to calculate, sort, retrieve data with greater speed than that of the human doing we can get results in less time.
Better Accuracy and Improved Consistency:
The computer carries out computing steps including arithmetic accurately and consistently from which really human is escaped which yields more fatigue and boredom.
Using computerization we can do the required operations with lower cost than manual process. Hence by computerization we can reduce the cost drastically.
Proposed HRMS is Computerized System. HRMS mainly deals with the activities taking place in an organization to process the resume details forwarded by the candidates. There are three main modules in this system, they are
In this module, HR Manager can give access rights to some of the employee of the organization by giving UserId and password. Generally in the organization there are five interview rounds.
The persons who have access rights to this system, they can define the interview rounds form the above five rounds and their order for recruiting of particular job.
They can Add new Positions for recruiting, Add Departments, Add Marital Status, Add Skill Type, Add Source, Add Languages Add Certifications, Add Rounds, Add Role of the employee who can access this application.
They will send the intimation letter for the written test to the selected applicants.
Junior Level Management Module:
In Junior Level Management the candidates who were called for written test will be conducted the different tests like written, technical, psychological organizational awareness and so on… In this module they generate reports depending on the applicants performance related to test results. Junior Level Management allows the applicant for the next level depending on their performance. After conducting all tests we will mail the intimation letter for the interview to the candidates who were selected in the module. Finally they will assign the applications to the interviewers for interview.
In this module senior level management interacts with the database for getting the details of selected applicants in the previous module. They will go through the applicant details and their Skill-sets reports. Again this management deals with the selected applicants in Jr level management selection process. Here senior level management conducts interview for these selected candidates. With these two modules details they will prepare the final candidates list for appointment and they will send the appointment letters to the selected applicants.
Functional requirements describe the high level functionality of thee system. It describes the interaction between the system and its environment independent of its implementation. Environment includes the user and any other external system with which the system interacts.
The following are the functional requirements of the HRMS:
Non-Functional requirements describe user -visible aspects of the system that are not directly related with the functional behavior of the system.
The following are the Nonfunctional requirements of the HRMS:
On the portion of the Application Assessment screen, you have the main menu, where various tabs are shown that form apart of each of the modules.
All projects are feasible, given unlimited resources and infinite time. But the development of software is plagued by the scarcity of resources and difficult delivery rates. It is both necessary and prudent to evaluate the feasibility of a project at the earliest possible time. Three key considerations are involved in the feasibility analysis.
This procedure is to determine the benefits and savings that are expected from a candidate system and compare them with costs. If benefits outweigh costs, then the decision is made to design and implement the system. Otherwise, further justification or alterations in proposed system will have to be made if it is to have a chance of being approved. This is an ongoing effort that improves in accuracy at each phase of the system life cycle.
Technical feasibility centers on the existing computer system (hardware, software, etc.,) and to what extent it can support the proposed addition. If the budget is a serious constraint, then the project is judged not feasible.
People are inherently resistant to change, and computers have been known to facilitate change. It is understandable that the introduction of a candidate system requires special effort to educate, sell, and train the staff on new ways of conducting business.
Human Resource Management System is the project that is designed mainly on Java. The main reason behind choosing the Java environment is that, keeping in mind the needs of the users. The activities that go on in this particular phase are acceptance of applicant’s profiles with the help of well designed web based forms and storing the information in the database and retrieving for future use. The usage of JSP facilitates the dynamic page generation. This is the main reason behind the usage of JAVA for the development of this project. Since it is multi platform environment that supports web Browser where as other languages lack these features.
In order to maintain continuously communicate between client and server he/she needs a reliable protocol i.e., is TCP/IP protocol. This protocol frequently transfers messages between client and server. Communication Standards such as HTTP is used .An HTTP is a client/server interaction consists of a single request/reply interchange, it user-friendly environment.
The Human Resource Management System is a system that maintains the information regarding the various applicant details. The entire system is designed to maintain information regarding the applied candidates and those candidates who are recruited. It also maintains information regarding the various tests conducted and the short listed candidates. Once candidates have been selected the left over candidate’s information is deleted from the database.
The Human Resource Management System efficiently manages the information coming into the database sends the list of eligible candidates that need to appear for scrutiny very fastly. Also it enables results to be processed in a very time saving and effective manner and short lists the names of all candidates’ selected and present details about their performance in a well organized, easily understandable manner. Various reports regarding the selected candidate’s performance and pay scale are also generated to provide minute details regarding the entire system.
HRMS was developed as a IAVA web application. It works efficiently; less time it generates web page when it works on Pentium IV Processor with RAM 1 GB.
It works up to ten concurrent users.
Initially HR Manager assign authentication rights to employee of the organization by giving usreid, password.
The authentication of the user is should verify by checking userid, password when ‘Login’.
Only authenticated users of the organization can access the system.
Java language was developed by James Gosling and his team at sun Micro systems and released formally in 1995. Its former name is oak. Java Development Kit 1.0 was released in 1996. to popularize java and is freely available on Internet.
Java is loosely based on C++ syntax, and is meant to be Object-Oriented Structure of java is midway between an interpreted and a compiled language java programs are compiled by the java compiler into Byte Codes which are secure and portable across different platforms. These byte codes are essentially instructions encapsulated in single type, to what is known as a java virtual machine (JVM) which resides in standard browser.
JVM verifies these byte codes when downloaded by the browser for integrity. JVM is available for almost all OS. JVM converts these byte Codes into machine specific instructions at runtime.
Java is strongly associated with internet and known as internet programming language. Internet users can use java to create applet programs and run them locally using java enabled browser search as hot java. Applets can be downloaded from remote machine via internet and run it on local machine.
World Wide Web is an open ended information retrieval system designed to be used in the distributed environment. This system contains web pages that provide both information and controls. We can navigate to a new web page in any direction. This is made possible worth HTML java was meant to be used in distributed environment such as internet. So java could be easily incorporated into the web system and is capable of supporting animation graphics, games and other special effect. The web has become more dynamic and interactive with support of java. We can run a java program on remote machine over internet with the support of web
Java environment includes a large no. of tools which are part of the system known as java development kit (JDK) and hundreds of classes, methods, and interfaces grouped into packages forms part of java standard library (JSL).
Java architecture provides a portable, robust, high performing environment for development. Java provides portability by compiling the byte codes for the java virtual machine which are then interpreted on each platform by the runtime environment java also provides stringent compile and runtime checking and automatic memory management in order to ensure solid code.
When we compile the code, java compiler creates machine code (byte code) for a hypothetical machine called java virtual machine (JVM). The JVM will execute the byte code and overcomes the issue of portability. The code is written and compile for one machine and interpreted all other machines. This machine is called java virtual machine.
HTML (hyper text markup language) is a language used to create hyper text documents that have hyper links embedded in them . it consists of tags embedded in the text of a document with HTML. We can build web pages or web document s. it is basically a formatting language and not a programming language. The browser reading the document interprets mark up tags to help format the document for subsequent display to a reader. HTML is a language for describing structured documents. HTML is a platform independent. WWW (World Wide Web) pages are written using HTML. HTML tags control in part the representation of the WWW page when view with web browser. The browser interprets HTML tags in the web document and displays it. Different browsers show data differently. Examples of browsers used to be web pages include:
Java script is a general purpose, prototype based, object oriented scripting language developed jointly by sun and Netscape and is meant for the WWW. It is designed to be embedded in diverse applications and systems, with out consuming much memory. Java script borrows most of its syntax from java but also inherits from awk and perl, with some indirect influence from self in its object prototype system.
Java scripts dynamically typed that is programs don’t declare variable types, and the type of variable is unrestricted and can change at runtime. Source can be generated at run time and evaluated against an arbitrary scope. Typical implementations compile by translating source into a specified byte code format, to check syntax and source consistency. Note that the availability to generate and interpret programs at runtime implies the presence of a compiler at runtime.
Java script is a high level scripting language that does not depend on or expose particular machine representations or operating system services. It provides automatic storage management, typically using a garbage collector.
It is a java data base connectivity having database as a back-end of java as front end. Database is a collectivity of related data. A data base management system (DBMS) controls the storage or retrieval of data in the database. The main use of this JDBC is the database connectivity.
Using drivers we can get connection to the back-end:
The package we use here is java. Sql.
Interfaces of jdbc include Driver, Connection, Statement, Prepare Statement, CallableStatement, ResultSet, and ResultSetMetaData.
Classes of JDBC are DriverManages, DriverPropertyInformation, Date, Time, Timestamp, and Type. The driver defined by the class JdbcOdbcDriver in package sun.jdbc.odbc. Class sun.jdbc.odbc.JdbcOdbcDriver represents the jdbc to odbc bridge driver.
The JDBC 1.0 API provided result sets that had the ability to scroll in a forward directionally. Scrollable result sets allow for more flexibility in the processing of results by providing both forward and backward movement through their contents. In addition, scrollable result sets allow for relative and absolute positioning. For example, its pos-sable to move to the fourth row in a scrollable result set directly, or to move directly to the third row following the current row, provided the row exists. The JDBC API allows result sets to be directly updatable, as well.
The batch update feature allows an application to submit multiple update statements (insert/update/delete) in a single request to the database. This can provide a dramatic increase in performance when a large number of update statements need to be executed.
Increased support for storing persistent Java programming language objects (Java objects) and a mapping for SQL99 data types such as binary large objects, and structured types, has been added to the JDBC API. An application may also customize the map-ping of SQL99 structured types into Java programming language classes.
As its name implies, a rowset encapsulates a set of rows. A rowset may or may not maintain an open database connection. When a rowset is ‘disconnected’ from its data source, updates performed on the rowset are propagated to the underlying database using an optimistic concurrency control algorithm. RowSets add support to the JDBC API for the JavaBeans component model. A RowSet object is a bean. A RowSet implementation may be Serializable. Rowsets can be created at design time and used in conjunction with other JavaBeans components in a visual builder tool to construct an application.
The Java Naming and Directory Interface (JNDI) API can be used in addition to a JDBC technology-based driver manager (JDBC driver manager) to obtain a connection to a database. When an application uses the JNDI API, it specifies a logical name that identifies a particular database instance and JDBC driver for accessing that database. This has the advantage of making the application code independent of a particular JDBC driver and JDBC technology URL.
The JDBC API contains ‘hooks’ that allow connection pooling to be implemented on top of the JDBC driver layer. This allows for a single connection cache that spans the different JDBC drivers that may be in use. Since creating and destroying database connections is expensive, connection pooling is important for achieving good performance, especially for server applications.
This chapter discusses the new functionality that has been added to result sets. The goal of the enhancements is to add two new basic capabilities to result sets: scrolling and updatability. Several methods have also been added to enable a JDBC driver to deliver improved performance when processing results. A variety of examples are included to illustrate the new features.
A result set created by executing a statement may support the ability to move backward (last-to-first) through its contents, as well as forward (first-to-last). Result sets that support this capability are called scrollable result sets. Result sets that are scrollable also support relative and absolute positioning. Absolute positioning is the ability to move directly to a row by specifying its absolute position in the result set, while relative positioning gives the ability to move to a row by specifying a position that is relative to the current row. The definition of absolute and relative positioning in the JDBC API is modeled on the X/Open SQL CLI specification.
The JDBC 1.0 API provided one result set type—forward-only. The JDBC 2.1 core API provides three result set types: forward-only, scroll-insensitive, and scroll-sensitive. As their names suggest, the new result set types support scrolling, but they differ in their ability to make changes visible while they are open.A scroll-insensitive result set is generally not sensitive to changes that are made while it is open. A scroll-insensitive result set provides a static view of the underlying data it contains. The membership, order, and column values of rows in a scroll-insensitive resultset are typically fixed when the result set is created. On the other hand, a scroll-sensitive result set is sensitive to changes that are made while it is open, and provides a ‘dynamic’ view of the underlying data. For example, when using a scroll-sensitive result set, changes in the underlying column values of rows are visible. The membership and ordering of rows in the result set may be fixed—this is implementation defined.
An application may choose from two different concurrency types for a result set: read-only and updatable. A result set that uses read-only concurrency does not allow updates of its contents. This can increase the overall level of concurrency between transactions, since any number of read-only locks may be held on a data item simultaneously. A result set that is updatable allows updates and may use database write locks to mediate access to the same data item by different transactions. Since only a single write lock may be held at a time on a data item, this can reduce concurrency. Alternatively, an optimistic concurrency control scheme may be used if it is thought that conflicting accesses to data will be rare. Optimistic concurrency control implementations typically compare rows either by value or by a version number to determine if an update conflict
Two performance hints may be given to a JDBC 2.1 technology-enabled driver to make access to result set data more efficient. Specifically, the number of rows to be fetched from the database each time more rows are needed can be specified, and a direction for processing the rows—forward, reverse, or unknown—can be given as well. These values can be changed for an individual result set at any time. A JDBC driver may ignore a performance hint if it chooses.
The example below illustrates creation of a result set that is forward-only and uses read-only concurrency. No performance hints are given by the example, so the driver is free to do whatever it thinks will result in the best performance. The transaction isolation level for the connection is not specified, so the default transaction isolation level of the underlying database is used for the result set that is created. Note that this code is just written using the JDBC 1.0 API, and that it produces the same type of result set that would have been produced by the JDBC 1.0 API.
Connection con =
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery("SELECT emp_no, salary FROM
The next example creates a scrollable result set that is updatable and sensitive to updates. Rows of data are requested to be fetched twenty-five at-a-time from the database.
Connection con = DriverManager.getConnection(“jdbc:odbc:dsnName",
Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,
ResultSet rs = stmt.executeQuery("SELECT emp_no,salary FROM
The example below creates a result set with the same attributes as the previous example,
however, a prepared statement is used to produce the result set.
PreparedStatement pstmt = con.prepareStatement("SELECT emp_no, salary FROM employees where emp_no = ?",
ResultSet rs = pstmt.executeQuery();
The method DatabaseMetaData.supportsResultSetType() can be called to see which result set types are supported by a JDBC driver. However, an application may still ask a JDBC driver to create a Statement, PreparedStatement,or CallableStatement object using a result set type that the driver does not support. In this case, the driver should issue an SQLWarning on the Connection that produces the statement and choose an alternative value for the result set type of the statement according to the following rules:
Similarly, the method DatabaseMetaData.supportsResultSetConcurrency() can be called to determine which concurrency types are supported by a driver. If an appli-cation asks a JDBC driver for a concurrency type that it does not support then the driver should issue an SQLWarning on the Connection that produces the statement and choose the alternative concurrency type. The choice of result set type should be made first if an application specifies both an unsupported result set type and an unsupported concurrency type.
In some instances, a JDBC driver may need to choose an alternate result set type or con-currency type for a ResultSet at statement execution time. For example, a SELECT statement that contains a join over multiple tables may not produce a ResultSet that is updatable. The JDBC driver should issue an SQLWarning in this case on the Statement, PreparedStatement,orCallableStatement that produces the ResultSet and
choose an appropriate result set type or concurrency type as described above. An appli-cation may determine the actual result set type and concurrency type of a ResultSet by calling the ResultSet.getType() and getConcurrency() methods, respectively.
A result set is updatable if its concurrency type is CONCUR_UPDATABLE. Rows in an Updatable result set may be updated, inserted, and deleted. The example below updates the first row of a result set. The ResultSet.updateXXX() methods are used to modify the value of an individual column in the current row, but do not update the underlying
database. When the ResultSet.updateRow() method is called the database is updated. Columns may be specified by name or number.
The updates that an application makes must be discarded by a JDBC driver if the appli-cationmoves the cursor from the current row before calling updateRow(). In addition, an application can call the ResultSet.cancelRowUpdates() method to explicitly cancel the updates that have been made to a row. The cancelRowUpdates() method must be called after calling updateXXX() and before calling updateRow(), otherwise
it has no effect. The following example illustrates deleting a row. The fifth row in the result set is deleted from the database.
The example below shows how a new row may be inserted into a result set. The JDBC API defines the concept of an insert row that is associated with each result set and is used as a staging area for creating the contents of a new row before it is inserted into the result set itself. The ResultSet.moveToInsertRow() method is used to position the result set’s cursor on the insert row. The ResultSet.updateXXX()and ResultSet.getXXX() methods are used to update and retrieve individual column values from the insert row. The contents of the insert row is undefined immediately after calling ResultSet.moveToInsertRow(). In other words, the value returned by calling a ResultSet.getXXX() method is undefined after moveToInsertRow() is called until the value is set by calling ResultSet.updateXXX(). Calling ResultSet.updateXXX() while on the insert row does not update the underlying database or the result set.
Once all of the column values are set in the insert row, ResultSet.insertRow() is called to update the result set and the database simulta-neously. If a column is not given a value by calling updateXXX() while on the insert row, or a column is missing from the result set, then that column must allow a null value. Otherwise, calling insertRow() throws an SQLException.
A result set remembers the current cursor position “in the result set” while its cursor is temporarily positioned on the insert row. To leave the insert row, any of the usual cursor positioning methods may be called, including the special method Result-Set.moveToCurrentRow() which returns the cursor to the row which was the current row before ResultSet.moveToInsertRow() was called. In the example above,
ResultSet.first() is called to leave the insert row and move to the first row of the resultset. Due to differences in database implementations, the JDBC API does not specify an ex-act set of SQL queries which must yield an updatable result set for JDBC drivers that support updatability. Developers can, however, generally expect queries which meet the following criteria to produce an updatable result set:
JDBC and accessing the database through applets and JDBC API via an intermediate server resulted server resulted in a new type of database model which is different from the client-server model. Based on number of intermediate server through the request should go it is named as single tire, two tire and multi tire architecture
In a single tier the server and client are the same in the sense that a client program that needs information (client) and the source of this type of architecture is also possible in java, in case flat files are used to store the data. However this is useful only in case of small applications. The advantage with this is the simplicity and portability of the application developed.
In two tier architecture the database resides in one machine and client in different machine they are connected through the network. In this type of architecture a database management takes control of the database and provides access to clients in a network. This software bundle is also called as the server. Software in different machines, requesting for information are called as the clients.
In the three-tier architecture, any number of servers can access the database that resides on server, which in turn server clients in a network. For example, you want to access the database using java applets, the applet running in some other machine, can send request only to the server from which it is down loaded. For this reason we will need to have a intermediate server which will accept the requests from applets and them to the actual database server. This intermediate server acts as a two-way communication channel also. This is the information or data from the database is passed on to the applet that is requesting it. This can be extended to make n tiers of servers, each server carrying to specific type of request from clients, however in practice only 3 tiers architecture is popular.
The JDBC drivers that we are aware of at this time fit into one of four categories:
Servlets provide a Java(TM)-based solution used to address the problems currently associated with doing server-side programming, including inextensible scripting solutions, platform-specific APIs, and incomplete interfaces. Servlets are objects that conform to a specific interface that can be plugged into a Java-based server. Servlets are to the server-side what applets are to the client-side — object bytecodes that can be dynamically loaded off the net. They differ from applets in that they are faceless objects (without graphics or a GUI component). They serve as platform-independent, dynamically-loadable, pluggable helper bytecode objects on the server side that can be used to dynamically extend server-side functionality.
Servlets are modules that extend request/response-oriented servers, such as Java-enabled web servers. For example, a servlet might be responsible for taking data in an HTML order-entry form and applying the business logic used to update a company’s order database.
Servlets are to servers what applets are to browsers. Unlike applets, however, servlets have no graphical user interface. Servlets can be embedded in many different servers because the servlet API, which you use to write servlets, assumes nothing about the server’s environment or protocol. Servlets have become most widely used within HTTP servers; many web servers support the Servlet API.
Servlets are an effective replacement for CGI scripts. They provide a way to generate dynamic documents that is both easier to write and faster to run. Servlets also address the problem of doing server-side programming with platform-specific APIs: they are developed with the Java Servlet API, a standard Java extension. So use servlets to handle HTTP client requests. For example, have servlets process data POSTed over HTTPS using an HTML form, including purchase order or credit card data. A servlet like this could be part of an order-entry and processing system, working with product and inventory databases, and perhaps an on-line payment system.
Here are a few more of the many applications for servlets:
The javax.servlet package provides interfaces and classes for writing servlets. The architecture of the package is described below.
The central abstraction in the Servlet API is the Servlet interface. All servlets implement this interface, either directly or, more commonly, by extending a class that implements it such as HttpServlet.
The Servlet interface declares, but does not implement, methods that manage the servlet and its communications with clients. Servlet writers provide some or all of these methods when developing a servlet.
When a servlet accepts a call from a client, it receives two objects:
ServletRequest and ServletResponse are interfaces defined by the javax.servlet package.
The ServletRequest interface allows the servlet access to:
The ServletResponse interface gives the servlet methods for replying to the client. It:
Interfaces that extend the ServletResponse interface give the servlet more protocol-specific capabilities. For example, the HttpServletResponse interface contains methods that allow the servlet to manipulate HTTP-specific header information.
The classes and interfaces described above make up a basic Servlet. HTTP servlets have some additional objects that provide session-tracking capabilities. The servlet writer can use these APIs to maintain state between the servlet and the client that persists across multiple connections during some time period. HTTP servlets also have objects that provide cookies. The servlet writer uses the cookie API to save data with the client and to retrieve this data.
Each servlet has the same life cycle:
When a server loads a servlet, the server runs the servlet’s init method. Initialization completes before client requests are handled and before the servlet is destroyed.
Even though most servlets are run in multi-threaded servers, servlets have no concurrency issues during servlet initialization. The server calls the init method once, when the server loads the servlet, and will not call the init method again unless the server is reloading the servlet. The server can not reload a servlet until after the server has destroyed the servlet by calling the destroy method.
The init method provided by the HttpServlet class initializes the servlet and logs the initialization. To do initialization specific to your servlet, override the init() method following these rules:
The second version of the init method calls the getInitParameter method. This method takes the parameter name as an argument and returns a String representation of the parameter’s value.
The specification of initialization parameters is server-specific. In the Java Web Server, the parameters are specified with a servlet is added then configured in the Administration Tool. For an explanation of the Administration screen where this setup is performed, see the Administration Tool: Adding Servlets online help document.
If, for some reason, you need to get the parameter names, use the getParameterNames method.
Destroying a Servlet
Servlets run until the server are destroys them, for example at the request of a system administrator. When a server destroys a servlet, the server runs the servlet’s destroy method. The method is run once; the server will not run that servlet again until after the server reloads and reinitializes the servlet.
When the destroy method runs, another thread might be running a service request. The Handling Service Threads at Servlet Termination section shows you how to provide a clean shutdown when there could be long-running threads still running service requests.
Using the Destroy Method
The destroy method provided by the HttpServlet class destroys the servlet and logs the destruction. To destroy any resources specific to your servlet, override the destroy method. The destroy method should undo any initialization work and synchronize persistent state with the current in-memory state.
All of a servlet’s service methods should be complete when a servlet is removed. The server tries to ensure this by calling the destroy method only after all service requests have returned, or after a server-specific grace period, whichever comes first. If your servlet has operations that take a long time to run (that is, operations that may run longer than the server’s grace period), the operations could still be running when destroy is called. You must make sure that any threads still handling client requests complete; the remainder of this section describes a technique for doing this.
If your servlet has potentially long-running service requests, use the following techniques to:
shutdown and, if necessary, stop working, clean up and return.
Tracking Service Requests
To track service requests, include a field in your servlet class that counts the number of service methods that are running. The field should have access methods to increment, decrement, and return its value.
An HTTP Servlet handles client requests through its service method. The service method supports standard HTTP client requests by dispatching each request to a method designed to handle that request. For example, the service method calls the doGet method shown earlier in the simple example servlet.
Requests and Responses
Methods in the HttpServlet class that handle client requests take two arguments:
An HttpServletRequest object provides access to HTTP header data, such as any cookies found in the request and the HTTP method with which the request was made. The HttpServletRequest object also allows you to obtain the arguments that the client sent as part of the request.
To access client data:
If you expect text data, the getReader method returns a
BufferedReader for you to use to read the raw data.
If you expect binary data, the getInputStream method returns a
ServletInputStream for you to use to read the raw data
Note: Use either a getParameter[Values] method or one of the methods that allow you to parse the data yourself. They can not be used together in a single request.
An HttpServletResponse object provides two ways of returning data to the user:
Use the getWriter method to return text data to the user, and the getOutputStream method for binary data. Closing the Writer or ServletOutputStream after you send the response allows the server to know when the response is complete.
You must set HTTP header data before you access the Writer or OutputStream. The HttpServletResponse class provides methods to access the header data. For example, the setContentType method sets the content type. (This header is often the only one manually set.)
The methods to which the service method delegates HTTP requests include,
By default, these methods return a BAD_REQUEST (400) error. Your servlet should override the method or methods designed to handle the HTTP interactions that it supports. This section shows you how to implement methods that handle the most common HTTP requests: GET and POST.
The HttpServlet’s service method also calls the doOptions method when the servlet receives an OPTIONS request, and doTrace when the servlet receives a TRACE request. The default implementation of doOptions automatically determines what HTTP options are supported and returns that information. The default implementation of doTrace causes a response with a message containing all of the headers sent in the trace request. These methods are not typically overridden.
Session T tracking is a flexible, lightweight mechanism that enables stateful programming on the web. Its general implementation serves as a basis for more sophisticated state models, such as persistent user profiles or multi-user sessions.
A session is a series of requests from the same user that occur during a time period. This transaction model for sessions has many benefits over the single-hit model. It can maintain state and user identity across multiple page requests. It can also construct a complex overview of user behavior that goes beyond reporting of user hits.
Session tracking gives servlets and other server-side applications the ability to keep state information about a user as the user moves through the site. Server-side applications can use this facility to create more stateful user experiences and to track who’s doing what on the site.
Java Web Server maintains user state by creating a Session object for each user on the site. These Session objects are stored and maintained on the server. When a user first makes a request to a site, the user is assigned a new Session object and a unique session ID. The session ID matches the user with the Session object in subsequent requests. The Session object is then passed as part of the request to the servlets that handle the request. Servlets can add information to Session objects or read information from them.
After the user has been idle for more than a certain period of time (30 minutes by default), the user’s session becomes invalid, and the corresponding Session object is destroyed.
A session is a set of requests originating from the same browser, going to the same server, bounded by a period of time. Loosely speaking, a session corresponds to a single sitting of a single anonymous user (anonymous because no explicit login or authentication is required to participate in session tracking).
The Session Tracker uses a session ID to match users with Session objects on the server side. The session ID is a string that is sent as a cookie to the browser when the user first accesses the server. On subsequent requests, the browser sends the session ID back as a cookie, and the server uses this cookie to find the session associated with that request.
There are situations, however, where cookies will not work. Some browsers, for example, do not support cookies. Other browsers allow the user to disable cookie support. In such cases, the Session Tracker must resort to a second method, URL rewriting, to track the user’s session.
URL rewriting involves finding all links that will be written back to the browser, and rewriting them to include the session ID..
URL conversions are required only if the servlet supports session tracking for browsers that do not support cookies or browsers that reject cookies. The consequences of not doing these conversions is that the user’s session will be lost if the user’s browser does not support cookies and the user clicks on an un-rewritten URL. Note that this can have consequences for other servlets. If one servlet does not follow these conventions, then a user’s session could potentially be lost for all servlets.
Page compilation is a feature of the Java Web Server that allows HTML pages containing Java code to be compiled and run as servlets. Page compilation also simplifies the task of supporting session tracking. To that end, if URL rewriting is enabled, page compilation automatically adds the encodeUrl call to links in the HTML page.
In addition to the Session object, there are a few more classes that may interest the servlet developer.
The HttpSessionContext is the object that contains all existing and valid sessions. The HttpSessionContext can be obtained by calling getSessionContext() on the Session object. The HttpSessionContext lets you find other Session objects by their IDs and list the IDs of all valid sessions.
HttpSessionBindingListener is an interface that can be implemented by objects placed into a Session. When the Session object is invalidated, its contained values are also removed from the system. Some of these values may be active objects that require cleanup operations when their session is invalidated. If a value in a Session object implements HttpSessionBindingListener, then the value is notified when the Session is invalidated, thereby giving the object a chance to perform any necessary cleanup operations.
An Internet site must be prepared to support many valid sessions. A large site, for example, might have hundreds, or even thousands, of simultaneously valid sessions. Because each session can contain arbitrary data objects placed there by the application servlets, the memory requirements for the entire system can grow prohibitively large.
To alleviate some of these problems, the session tracking system places a limit on the number of Session objects that can exist in memory. This limit is set in the session.maxresidents property. When the number of simultaneous sessions exceeds this number, the Session Tracker swaps the least recently-used sessions out to files on disk. Those sessions are not lost: they will be reloaded into memory if further requests come in for those sessions. This system allows for more sessions to remain valid than could exist in memory. Session invalidation is not affected by session swapping. If a session goes unused for longer than the normal invalidation time, the session is invalidated, whether it is in memory or on disk. Session invalidation is set in the session.invalidationinterval property.
Sessions are written to and read from disk using Java serialization. For this reason, only serializable objects put into the Session object will be written to disk. Any objects put into the Session object that are not serializable will remain in memory, even if the rest of the Session object has been written to disk. This does not affect session tracking, but does reduce the memory savings that the Session Tracker gets from swapping a session to disk. For this reason, the servlet developer should try to put only serializable objects into the Session object. Serializable objects are those that implement either java.io.Serializable or java.io.Externalizable.
The session-swapping mechanism is also used to implement session persistence, if the session persistence feature is enabled. When the server is shut down, sessions still in memory are written to the disk as specified in the session.swapdirectory property. When the server starts again, ssions that were written to disk will once again become valid. This allows the server to be restarted without losing existing sessions. Only serializable data elements in the session will survive this shutdown/restart operation.
Note: Session persistence is intended for preserving sessions across server restarts. It is not meant to be used as a general long-term session persistence mechanism.
Session-tracking interfaces are in the javax.servlet.http package.
You can customize properties in the Session Tracker. The properties are kept in the server.properties files at:
where <server_root> is the directory into which you installed the Java Web Server product.
Note: These property settings are applied to all sessions, and cannot be tuned for individual sessions.
Time interval when Java Web Server checks for sessions that have gone unused long enough to be invalidated. Value is an integer, specifying the interval in milliseconds.
Time interval when Java Web Server checks if too many sessions are in memory, causing the overflow of sessions to be swapped to disk. Value is an integer, specifying the interval in milliseconds.
Boolean value specifying if Java Web Server keeps session data persistent. If true, sessions are swapped to disk when Java Web Server shuts down and are revalidated from disk when it restarts. If false, Java Web Server removes session swap files every time it starts.
Name of directory that the Java Web Server uses to swap out session data. No other data should be kept in this directory.
Number of sessions allowed to remain in memory at once. If the number of sessions exceeds this number, sessions will be swapped out to disk on a least recently used basis to reduce the number of resident sessions.
Amount of time a session is allowed to go unused before it is invalidated. Value is specified in milliseconds.
Boolean value specifying whether Session Tracking is active. If false, then the Java Web Server performs no function for extracting or inserting session IDs into requests.
Boolean value indicating whether Java Web Server uses rewritten URLs as a vehicle to carry the session ID. If true, then session IDs arriving in the URL are recognized, and the Java Web Server rewrites URLs if necessary to send the session ID.
Boolean value indicating whether the session ID is added to URLs when the URL dictates a switch from "http" to "https" or vice-versa.
Name of the cookie used to carry the session ID, if cookies are in use.
Comment of the cookie used to carry the session ID, if cookies are in use.
Java Web Server Session Tracking Cookie
If present, this defines the value of the domain field that is sent for session cookies.
If present, this defines the value of the maximum age of the cookie.
If present, this defines the value of the path field that will be sent for session cookies.
If true, then session cookies will include the secure field.
JavaServer Pages technology lets you put snippets of servlet code directly into a text-based document. A JSP page is a text-based document that contains two types of text: static template data, which can be expressed in any text-based format such as HTML, WML, and XML, and JSP elements, which determine how the page constructs dynamic content.
Oracle is a relational database management system, which organizes data in the form of tables. Oracle is one of many database servers based on RDBMS model, which manages a seer of data that attends three specific things-data structures, data integrity and data manipulation. With oracle cooperative server technology we can realize the benefits of open, relational systems for all the applications. Oracle makes efficient use of all systems resources, on all hardware architecture; to deliver unmatched performance, price performance and scalability. Any DBMS to be called as RDBMS has to satisfy Dr.E.F.Codd’s rules.
The Oracle RDBMS is available on wide range o f platforms ranging from PCs to super computers and as a multi user loadable module for Novel NetWare, if you develop application on system you can run the same application on other systems without any modifications.
Oracle commands can be used for communicating with IBM DB2 mainframe RDBMS that is different from Oracle, that is Oracle compatible with DB2. Oracle RDBMS is a high performance fault tolerant DBMS, which is specially designed for online transaction processing and for handling large database applications.
Oracle adaptable multithreaded server architecture delivers scalable high performance for very large number of users on all hardware architecture including symmetric multiprocessors (sumps) and loosely coupled multiprocessors. Performance is achieved by eliminating CPU, I/O, memory and operating system bottlenecks and by optimizing the Oracle DBMS server code to eliminate all internal bottlenecks.
Most popular RDBMS in the market because of its ease of use
12.DB procedures, functions and packages.
These rules are used for valuating a product to be called as relational database management systems. Out of 12 rules, a RDBMS product
hould satisfy at least 8 rules +rule called rule 0 that must be satisfied.
For any system that is to be advertised as, or claimed to be relational DBMS. That system should manage database with in it self, with out using an external language.
All information in relational database is represented at logical level in only one way as values in tables.
Each and every data in a relational database is guaranteed to be logically accessibility by using to a combination of table name, primary key value and column name
Null values are supported for representing missing information and inapplicable information. They must be handled in systematic way, independent of data types.
The database description is represented at the logical level in the same way as ordinary data so that authorized users can apply the same relational language to its interrogation as they do to the regular data.
A relational system may support several languages and various models of terminal use. However there must be one language whose statement can express all of the following:
Data Definitions, View Definitions, Data Manipulations, Integrity, Constraints, Authorization and transaction boundaries.
Any view that is theoretical can be updatable if changes can be made to the tables that effect the desired changes in the view.
The capability of handling a base relational or derived relational as a single operand applies not only retrieval of data also to its insertion, updating, and deletion.
Application program and terminal activities remain logically unimpaired whenever any changes are made in either storage representation or access method.
Application programs and terminal activities remain logically unimpaired whenever any changes are made in either storage representation or access methods.
Integrity constraints specific to particular database must be definable in the relational data stored in the catalog, not in application program.
Whether or not a system support database distribution, it must have a data sub-language that can support distributed databases without changing the application program.
If a relational system has low level language, that low language cannot use to subversion or by pass the integrity rules and constraints expressed in the higher level relational language.
Rule 1: Information Rule (Representation of information)-YES.
Rule 2: Guaranteed Access-YES.
Rule 3: Systematic treatment of Null values-YES.
Rule 4: Dynamic on-line catalog-based Relational Model-YES.
Rule 5: Comprehensive data sub language-YES.
Rule 6: View Updating-PARTIAL.
Rule 7: High-level Update, Insert and Delete-YES.
Rule 8: Physical data Independence-PARTIAL.
Rule 9: Logical data Independence-PARTIAL.
Rule 10: Integrity Independence-PARTIAL.
Rule 11: Distributed Independence-YES.
Rule 12: Non-subversion-YES.
We will send an essay sample to you in 2 Hours. If you need help faster you can always use our custom writing service.Get help with my paper