MBD Lifecycle The Message driven bean has two states-the 'does not exist' state and the

'method-ready' state. Initially the bean exists in the does not exist state. When the container starts up it may load a few instances into memory so that they can be in the ready state to consume messages. When a bean moves from the 'does not exist' state to the 'method-ready' state, the container first invokes the Class.newInstance() method to create a new instance of the bean. It then invokes the setMessageDrivenContext() method to set the reference to the ejbContext. This provides a reference to the MessageDrivenContext Interface which is in turn used to handle transaction and security issues in the MDB. Finally the ejbCreate() method is invoked by the container. Message driven beans have only one ejbCreate() method and they are called only once in the lifetime of a Message driven bean. When the bean is in the 'method-ready' state it is ready to consume messages. The container allocates a bean to consume a message when it arrives in the container. When a bean is servicing a message it cannot service another message. Subsequent messages are delegated to other instances existing in the pool. Once the bean is done servicing a message it is again returned to the 'method-ready' and is ready to process a new message. If the container cannot find a bean in the pool to service a message it transitions another bean from the 'does not exist' state to the 'method-ready' state. Bean instances leave the Method-Ready Pool for the Does Not Exist state when the server no longer needs them. This occurs when the server decides to reduce the total size of the Method-Ready Pool by removing one or more instances from memory. The process begins by invoking the ejbRemove() method on the instance. At this time, the bean instance should perform any cleanup operations, such as closing open resources. The ejbRemove() method is invoked only once in the life cycle of an MDB instance--when it is about to transition to the Does Not Exist state. During the ejbRemove() method, the MessageDrivenContext and access to the JNDI ENC are still available to the bean instance. Following the execution of the ejbRemove() method, the bean is dereferenced and eventually garbage collected.

JSP Implicit Objects

Implicit objects in jsp are the objects that are created by the container automatically and the container makes them available to the developers, the developer do not need to create them explicitly. Since these objects are created automatically by the container and are accessed using standard variables; hence, they are called implicit objects. The implicit objects are parsed by the container and inserted into the generated servlet code. They are available only within the jspService method and not in any declaration. Implicit objects are used for different

purposes. Our own methods (user defined methods) can't access them as they are local to the service method and are created at the conversion time of a jsp into a servlet. But we can pass them to our own method if we wish to use them locally in those functions. There are nine implicit objects. Here is the list of all the implicit objects: Object Class application javax.servlet.ServletContext config javax.servlet.ServletConfig exception java.lang.Throwable out javax.servlet.jsp.JspWriter page java.lang.Object PageContext javax.servlet.jsp.PageContext request javax.servlet.ServletRequest response javax.servlet.ServletResponse session javax.servlet.http.HttpSession

Application: These objects has an application scope. These objects are available at the widest context level, that allows to share the same information between the JSP page's servlet and any Web components with in the same application. Config: These object has a page scope and is an instance of javax.servlet.ServletConfig class. Config object allows to pass the initialization data to a JSP page's servlet. Parameters of this objects can be set in the deployment descriptor (web.xml) inside the element <jsp-file>. The method getInitParameter() is used to access the initialization parameters. Exception: This object has a page scope and is an instance of java.lang.Throwable class. This object allows the exception data to be accessed only by designated JSP "error pages." Out: This object allows us to access the servlet's output stream and has a page scope. Out object is an instance of javax.servlet.jsp.JspWriter class. It provides the output stream that enable access to the servlet's output stream. Page: This object has a page scope and is an instance of the JSP page's servlet class that processes the current request. Page object represents the current page that is used to call the methods defined by the translated servlet class. First type cast the servlet before accessing any method of the servlet through the page. Pagecontext: PageContext has a page scope. Pagecontext is the context for the JSP page itself that provides a single API to manage the various scoped attributes. This API is extensively used if we are implementing JSP custom tag handlers. PageContext also provides access to several page attributes like including some static or dynamic resource. Request: Request object has a request scope that is used to access the HTTP request data, and also provides a context to associate the request-specific data. Request object implements javax.servlet.ServletRequest interface. It uses the getParameter() method to access the request parameter. The container passes this object to the _jspService() method. Response: This object has a page scope that allows direct access to the HTTPServletResponse class object. Response object is an instance of the classes that implements the javax.servlet.ServletResponse class. Container generates to this object and passes to the _jspService() method as a parameter. Session: Session object has a session scope that is an instance of javax.servlet.http.HttpSession class. Perhaps it is the most commonly used object to manage the state contexts. This object persist information across multiple user connection.

IDL (interface definition language)

1) IDL (interface definition language) is a generic term for a language that lets a program or object written in one language communicate with another program written in an unknown language. In distributed object technology, it's important that new objects be able to be sent to any platform environment and discover how to run in that environment. An Object Request Broker ( ORB ) is an example of a program that would use an interface definition language to "broker" communication between one object program and another one. An interface definition language works by requiring that a program's interfaces be described in a stub or slight extension of the program that is compiled into it. The stubs in each program are used by a broker program to allow them to communicate. 2) IDL (Interactive Data Language) is a language for creating visualizations based on scientific or other data. 3) IDL (interactive distance learning) is a general term for learning that takes place through remote telecommunication and that allows students to participate from a distance. Television has been used for many years for non-interactive distance learning. Teleconference classes are becoming more common where higher bandwidth and such technologies as ISDN and satellite communication permit. The World Wide Web, with or without multimedia, offers new possibilities.

Servlet Life Cycle

The Servlet life cycle (see Figure 2-1) is the primary reason Servlets and also JSP outperform traditional CGI. Opposed to the single-use CGI life cycle, Servlets follow a three-phase life: initialization, service, and destruction, with initialization and destruction typically performed once, and service performed many times. Figure 2-1. Diagram of the Servlet Life Cycle Initialization is the first phase of the Servlet life cycle and represents the creation and initialization of resources the Servlet may need to service requests. All Servlets must implement the javax.servlet.Servlet interface. This interface defines the init() method to match the initialization phase of a Servlet life cycle. When a container loads a Servlet, it invokes the init() method before servicing any requests. The service phase of the Servlet life cycle represents all interactions with requests until the Servlet is destroyed. The Servlet interface matches the service phase of the Servlet life cycle to the service() method. The service() method of a Servlet is invoked once per a request and is responsible for generating the response to that request. The Servlet specification defines the service() method to take two parameters: a javax.servlet.ServletRequest and a javax.servlet.ServletResponse object. These two objects represent a client's request for the dynamic resource and the Servlet's response to the client. By default a Servlet is multi-threaded, meaning that typically only one instance of a Servlet1 is loaded by a JSP container at any given time. Initialization is done once, and each request after that is handled concurrently2 by threads executing the Servlet's service() method. The destruction phase of the Servlet life cycle represents when a Servlet is being removed from use by a container. The Servlet interface defines the destroy() method to correspond to the destruction life cycle phase. Each time a Servlet is about to be removed from use, a container calls the destroy() method, allowing the Servlet to gracefully terminate and tidy up any resources it might have created. By proper use of the initialization, service, and destruction phases of the Servlet life cycle, a Servlet can efficiently manage

application resources. During initialization a Servlet loads everything it needs to use for servicing requests. The resources are then readily used during the service phase and can then be cleaned up in the destruction phase.
Servlet API

The Java Servlet API defines the interface between servlets and servers. This API is packaged as a standard extension to the JDK under javax:

Package javax.servlet Package javax.servlet.http

The API provides support in four categories:

Servlet life cycle management Access to servlet context Utility classes HTTP-specific support classes

The Servlet Life Cycle

Servlets run on the web server platform as part of the same process as the web server itself. The web server is responsible for initializing, invoking, and destroying each servlet instance. A web server communicates with a servlet through a simple interface, javax.servlet.Servlet. This interface consists of three main methods:
init() service() destroy()

and two ancillary methods:

getServletConfig() getServletInfo()

You may notice a similarity between this interface and that of Java applets. This is by design! Servlets are to web servers what applets are to web browsers.An applet runs in a web browser, performing actions it requests through a specific interface. A servlet does the same, running in the web server.
The init() Method

When a servlet is first loaded, its init() method is invoked. This allows the servlet to per form any setup processing such as opening files or establishing connections to their servers. If a servlet has been permanently installed in a server, it loads when the server starts to run. Otherwise, the server activates a servlet when it receives the first client request for the services provided by the servlet. The init() method is guaranteed to finish before any other calls are made to the servlet--such as a call to the service() method. Note that init() will only be called once; it will not be called again unless the servlet has been unloaded and then reloaded by the server.

The init() method takes one argument, a reference to a ServletConfig object which provides initialization arguments for the servlet. This object has a method getServletContext() that returns a ServletContext object containing information about the servlet's environment (see the discussion on Servlet Initialization Context below).
The service() Method

The service() method is the heart of the servlet. Each request message from a client results in a single call to the servlet's service() method. The service() method reads the request and produces the response message from its two parameters:

A ServletRequest object with data from the client. The data consists of name/value pairs of parameters and an InputStream. Several methods are provided that return the client's parameter information. The InputStream from the client can be obtained via the getInputStream() method. This method returns a ServletInputStream, which can be used to get additional data from the client. If you are interested in processing character-level data instead of byte-level data, you can get a BufferedReader instead with getReader(). A ServletResponse represents the servlet's reply back to the client. When preparing a response, the method setContentType() is called first to set the MIME type of the reply. Next, the method getOutputStream() or getWriter() can be used to obtain a ServletOutputStream or PrintWriter, respectively, to send data back to the client.

As you can see, there are two ways for a client to send information to a servlet. The first is to send parameter values and the second is to send information via the InputStream (or Reader). Parameter values can be embedded into a URL. How this is done is discussed below. How the parameter values are read by the servlet is discussed later. The service() method's job is conceptually simple--it creates a response for each client request sent to it from the host server. However, it is important to realize that there can be multiple service requests being processed at once. If your service method requires any outside resources, such as files, databases, or some external data, you must ensure that resource access is thread-safe. Making your servlets thread-safe is discussed in a later section of this course.
The destroy() Method

The destroy() method is called to allow your servlet to clean up any resources (such as open files or database connections) before the servlet is unloaded. If you do not require any clean-up operations, this can be an empty method. The server waits to call the destroy() method until either all service calls are complete, or a certain amount of time has passed. This means that the destroy() method can be called while some longer-running service() methods are still running. It is important that you write your destroy() method to avoid closing any necessary resources until all service() calls have completed.

What is the difference between JDBC and ODBC?

a) OBDC is for Microsoft and JDBC is for Java applications. b) ODBC cant be directly used with Java because it uses a C interface. c) ODBC makes use of pointers which have been removed totally from Java. d) ODBC mixes simple and advanced features together and has complex options for simple queries. But JDBC is designed to keep things simple while allowing advanced capabilities when required. e) ODBC requires manual installation of the ODBC driver manager and driver on all client machines. JDBC drivers are written in Java and JDBC code is automatically installable, secure, and portable on all platforms. f) JDBC API is a natural Java interface and is built on ODBC. JDBC retains some of the basic features of ODBC.

b) *ODBC is for microsoft & JDBC is for java applications c) d) * ODBC can't be directly used with java because it uses a c e) interface. f) g) *ODBC makes use of pointers which have been h) removed totally from java. i) j) *ODBC is procedural-oriented & JDBC is Object-Oriented k) l) *ODBC is used to provide connection between front-end and m) back-end.JDBC is used to provide connection between java n) and database. o) p) *ODBC is language -independent&JDBC is language-dependent. q) r) *ODBC mixes simple & advanced features together and has s) complex options for simple queries.JDBC is designed to keep t) things simple while allowing advanced capabilities when u) required. v) w) *ODBC requires manual installation of the ODBC driver x) manager and driver on all client machines.JDBC drivers are y) written in java and JDBC code is automatically z) installable,secure and portable on all platforms.
aa)

JNDI is a Java API for accessing naming and directory services (hence its name), while LDAP is a particular kind of directory service. The Lightweight Directory Access Protocol (LDAP) is a network protocol for accessing directories. It is based on the X.500, a CCITT standard for directory services that is part of the OSI suite of services.

SP Life Cycle explain.

05/05/2008

JSPs life cycle can be grouped into following phases.

1. JSP Page Translation:

A java servlet file is generated from the JSP source file. This is the first step in its tedious multiple phase life cycle. In the translation phase, the container validates the syntactic correctness of the JSP pages and tag files. The container interprets the standard directives and actions, and the custom actions referencing tag libraries used in the page.

2. JSP Page Compilation:

The generated java servlet file is compiled into a java servlet class. Note: The translation of a JSP source page into its implementation class can happen at any time between initial deployment of the JSP page into the JSP container and the receipt and processing of a client request for the target JSP page.

3. Class Loading:
The java servlet class that was compiled from the JSP source is loaded into the container.

4. Execution phase:
In the execution phase the container manages one or more instances of this class in response to requests and other events. The interface JspPage contains jspInit() and jspDestroy(). The JSP specification has provided a special interface HttpJspPage for JSP pages serving HTTP requests and this interface contains _jspService().

5. Initialization:
jspInit() method is called immediately after the instance was created. It is called only once during JSP life cycle.

6. _jspService() execution:
This method is called for every request of this JSP during its life cycle. This is where it serves the purpose of creation. Oops! it has to pass through all the above steps to reach this phase. It passes the request and the response objects. _jspService() cannot be overridden.

7. jspDestroy() execution:
This method is called when this JSP is destroyed. With this call the servlet serves its purpose and submits itself to heaven (garbage collection). This is the end of jsp life cycle. jspInit(), _jspService() and jspDestroy() are called the life cycle methods of the JSP.

JSP Implicit Objects

11/05/2008

JSP Implicit objects are created by the web container. These implicit objects are Java objects that implement interfaces in the Servlet and JSP API. Scripting elements in a JSP page can make use of these JSP implicit objects. There are nine (9) JSP implicit objects available.

JSP Implicit Objects are as follows:

1. request implicit object

The JSP implicit request object is an instance of a java class that implements the javax.servlet.http.HttpServletRequest interface. It represents the request made by the client. The request implicit object is generally used to get request parameters, request attributes, header information and query string values.
2. response implicit object

The JSP implicit response object is an instance of a java class that implements the javax.servlet.http.HttpServletResponse interface. It represents the response to be given to the client. The response implicit object is generally used to set the response content type, add cookie and redirect the response.
3. out implicit object

The JSP implicit out object is an instance of the javax.servlet.jsp.JspWriter class. It represents the output content to be sent to the client. The out implicit object is used to write the output content.
4. session implicit object

The JSP implicit session object is an instance of a java class that implements the javax.servlet.http.HttpSession interface. It represents a client specific conversation. The session implicit object is used to store session state for a single user.
5. application implicit object

The JSP implicit application object is an instance of a java class that implements the javax.servlet.ServletContext interface. It gives facility for a JSP page to obtain and set information about the web application in which it is running.
6. exception implicit object

The JSP implicit exception object is an instance of the java.lang.Throwable class. It is available in JSP error pages only. It represents the occured exception that caused the control to pass to the JSP error page.
7. config implicit object

The JSP implicit config object is an instance of the java class that implements javax.servlet.ServletConfig interface. It gives facility for a JSP page to obtain the initialization parameters available.
8. page implicit object

The JSP implicit page object is an instance of the java.lang.Object class. It represents the current JSP page. That is, it serves as a reference to the java servlet object that implements the JSP page on which it is accessed. It is not advisable to use this page implict object often as it consumes large memory.
9. pageContext implicit object

The JSP implicit pageContext object is an instance of the javax.servlet.jsp.PageContext abstract class. It provides useful context information. That is it provides methods to get and set attributes in different scopes and for transfering requests to other resources. Also it contains the reference to to implicit objects.

Servlet Life Cycle

05/05/2008

The interface javax.servlet.Servlet defines the following three methods known as servlet life cycle methods. public void init(ServletConfig config) throws ServletException public void service(ServletRequest req, ServletResponse res) throws ServletException, java.io.IOException public void destroy()

1. Creation and initialization

The container first creates the servlet instance and then executes the init() method. init() can be called only once in its life cycle by the following ways: a) Through the load-on-startup tag using the web.xml. This makes the servlet to be loaded and initialized when the server starts. b) For the first time only in its life cycle, just before the service() is invoked. c) Server administrator can request for the initialization of a servlet directly.

2. Execution of service
Whenever a client requests for the servlet, everytime the service() method is invoked during its life cycle. From service() then it is branched to the doGet() or doXx..() methods for a HttpServlet. The service() method should contain the code that serves the Servlet purpose.

3. Destroy the servlet

destroy() method is invoked first, then Servlet is removed from the container and then eventually garbage collected. destroy() method generally contains code to free any resources like jdbc connection that will not be garbage collected.

JSP Tags

In this JSP tutorial, you will learn about JSP tags, list of the tags used in Java Server Pages, declaration tag, general syntax of declaration tag, expression tag and general syntax of expression tag. Tags are a vital concept in Java Server Pages (JSP). Below is a list of tags used in JSP. This section discusses Declaration Tag and Expression Tag in detail; syntax, usage with examples and explanations for both.
List of the tags used in Java Server Pages:

Declaration tag Expression tag Directive tag Scriptlet tag Action tag

. Syntax, usage and example of Declaration Tag and Expression Tag:

Declaration tag:

Declaration tag is used to define functions, methods and variables that will be used in Java Server Pages. Notation of the Declaration tag is shown below: <%! %> At the start of Declaration tag one must place <%! Inside Declaration tag one can declare variables or methods. Declaration tag ends with the notation %>. Also care must be taken to place a semicolon that is ; at the end of each code placed inside Declaration tag.
General syntax of Declaration Tag:
<%! statement1; statement2; ..........; ..........; %> //start of declaration tag //variables or methods declaration //end of declaration tag

For example:

<%! private int example = 0 ; private int test = 5 ; %>

Expression tag:

Expression tag is used to display output of any data on the generated page. The data placed in Expression tag prints on the output stream and automatically converts data into string. The Expression tag can contain any Java expression used for printing output equivalent to out.println().Thus, an expression tag contains a scripting language expression which is evaluated, automatically converts data to a String and the outputs are displayed. Notation of Expression tag is shown below: <%= %> Expression tag must begin with <%= Inside Expression tag, the user embeds any Java expression. Expression tag ends with the notation %>. NOTE: Expression should not contain a semicolon between codes, as with Declaration tag.
General syntax of Expression Tag:
<%! statement %> //start of declaration tag //Java Expression //end of declaration tag

For example:
<%! Exfdate: <%= new java.util.Date() %> %>

Above example displays current date and time as Date() is placed inside the Expression tag <%= %>
Directive tag:

The directive tag gives special information about the page to JSP Engine. This changes the way JSP Engine processes the page. Using directive tag, user can import packages, define error handling pages or session information of JSP page. General notation of directive tag is as follows: There are three types of directive tag.

page Include Tag Lib

Syntax and usage of directive tag

page directive:

General syntax for the page directive is <%@ page optional attribute ... %> There are many optional attributes available for page directive. Each of these attributes are used to give special processing information to the JSP Engine changing the way the JSP Engine processes the page. Some of the optional attributes available for page directive are:

language extends import session buffer autoFlush isThreadSafe info errorPage IsErrorPage contentType

Syntax and usage of some of the optional attributes available for page directive discussed below.
language:

This attribute is used to denote the language used by a file. Language denotes the scripting language used in scriptlets, declarations, and expressions in the JSP page and any included files. Syntax of language attribute available for page directive is <%@ page language = "lang" %> In the above statement page and language are keywords and one places whatever language the file uses inside " ". For example if one wants to mention the language as java which is generally mentioned for all it is done as shown below: <%@ page language = "java" %>
extends:

This is used to signify the fully qualified name of the Super class of the Java class used by the JSP engine for the translated Servlet. Syntax of extends attribute available for page directive is <%@ page extends = "package.class"%> In the above statement page and extends are keywords.

import:

The import attribute is used to import all the classes in a java package into the current JSP page. With this facility, the JSP page can use other java classes. Syntax of import attribute available for page directive is <%@ page import = "java.util.*" %> In the above statement page and import are keywords. If there are many Java packages that the JSP page wants to import, the programmer can use import more than once in a JSP page or separate the Java packages with commas, as shown below: <%@ page import="{package.class | package.*}, ..." %>
session:

The session attribute, when set to true, sets the page to make use of sessions. NOTE: by default, the session attribute value is set to true therefore, all JSP pages have session data available. If the user sets the session attribute to false, it should be performed in this section. When the session attribution is set to false, the user cannot use the session object, or a <jsp:useBean> element with scope=session in the JSP page which, if used, would give error. Syntax of session attribute available for page directive is <%@ page session="true|false" %> In the above statement page and session are keywords. And either true or false value can be setted and by default the value is true.
buffer:

If a programmer likes to control the use of buffered output for a JSP page then the buffer attribute can be made use of for achieving this. Syntax of buffer attribute available for page directive is <%@ page buffer = "none|8kb|sizekb" %> In the above statement page and buffer are keywords. The size of buffer size is mentioned in kilobytes. This is used by the out object to handle output sent from the compiled JSP page to the client web browser. The default value is 8kb. If a user specifies a buffer size then the output is buffered with at least the size mentioned by the user. For example one can specify as: <%@ page buffer = "none" %>

Scriptlet tag:
Scriptlet tag is a type tag used for inserting Java Code into JSP.

Notation of the Scriptlet tag is:

&lt;% %&gt;

To begin the Scriptlet tag, the user must add &lt;% . Inside the Scriptlet tag, the user can add any valid Scriptlet, meaning any valid Java Code. User can write the code in between the Scriptlet tag accesses any variable or bean declared. The Scriptlet tag ends with the notation %&gt;. NOTE: there must be semicolon ; included at the end of each code inside the Scriptlet tag. General syntax of Scriptlet Tag:

&lt;%! statement1; statement2; ..........; ..........; %&gt;

//Valid Java Code //end of Scriptlet tag

For instance

&lt;% for (int j = 0; j &lt;5; j++) { out.print(j); } %&gt;

In the above example, the Java code embeds inside the tag &lt;% and %&gt;. NOTE: at the end of the statement, a semicolon ; is appended. Action Tag:

Action tag is used to transfer the control between pages and is also used to enable the use of server side JavaBeans. Instead of using Java code, the programmer uses special JSP action tags to either link to a Java Bean set its properties, or get its properties. General syntax of Action Tag:

<jsp:action attributes />

In the above statement jsp is a keyword.

There are many action tags that are available for Java Server Pages. The most commonly used action tags are three of them and they are namely:

include forward useBean

Syntax, attributes and usage of above three action tags are provided in brief.
include action tag:

include is a type of directive tag. include tag has the same concept as that of the include directive. The include tag is used to include either static or dynamic content, wherever required. General syntax of include action Tag:
<jsp:include page="{relativeURL | <%= expression %>}" flush="true" />

In the above statement, the words jsp, include, flush and page are keywords. The include action tag includes a static file or it is used to send a request to a dynamic file. If the included file is a static file, the contents are included as such in the called JSP file. In contrast, if the included file is dynamic, then a request sends to the dynamic file. Once the include action is completed, the result is sent back. If the file is dynamic one can use the syntax as below:
<jsp:include page="{relativeURL | <%= expression %>}" flush="true" /> <jsp:param name="parameterName" value="{parameterValue | <%= expression %>}" /> </jsp:include>

The file is dynamic and extra attribute clause passed is jsp:param clause, and this is used to pass the name and value of a parameter to the dynamic file. In the above, the words jsp, include, flush, page, param, name and value are keywords. In the above syntax for dynamic file inclusion, the name attribute specifies the parameter name and its case-sensitive literal string. The value attribute specifies the parameter value, taking either a case-sensitive literal string or an expression that is evaluated at request time. In the syntax of include action Tag we relative URL placed within " " denotes the location of the file to be included or denotes the pathname to be included. This can also be an expression which is taken automatically as string, denoting the relative URL. NOTE: the pathname must not contain the protocol name, port number, or domain name. Both absolute and relative representations can be made for denoting the URL. The flush attribute can only take on value "true" as mentioned in syntax notation. NOTE: Do not to include the value if false for the flush attribute.

The syntax used for including dynamic file had &lt;jsp:param&gt; clause allows the user to pass one or more name/value pairs as parameters to an included file. This is the syntax for dynamic file, meaning that the included file is a dynamic file (i.e. either a JSP file or a servlet, or other dynamic file). Also, the user can pass more than one parameter to the included file by using more than one &lt;jsp:param&gt; clause. For example: An example to include a static file exforsys.html in the include action tag:
<jsp:include page="exforsys.html" flush="true" />

Let us see an example of dynamic file inclusion in the include action tag which is done as below:
<jsp:include page="example/test.jsp"> <jsp:include name="username" value="exforsys" /> </jsp:include>

Let us see about the other two commonly used action tags namely forward action tag and useBean action tag with syntax, usage, example and explanation in detail
forward action tag:

The forward action tag is used to transfer control to a static or dynamic resource. The static or dynamic resource to which control has to be transferred is represented as a URL. The user can have the target file as an HTML file, another JSP file, or a servlet. Any of the above is permitted. NOTE: The target file must be in the same application context as the forwarding JSP file. General syntax of forward action Tag:
<jsp:forward page="{relativeURL | <%= expression %>}" /> &nbsp;

Another syntax representation for forward action Tag is as below:

<jsp:forward page ="{relativeURL | <%= expression %>}" /> <jsp:param name ="parameterName" value="parameterValue" | <%= expression %>}" /> </jsp:forward>

In the above statement, jsp, forward, page, param, name and value are all keywords. The relative URL of the file to which the request is forwarded is represented as a String, an expression or as absolute or relative representation to the current JSP file denoting the pathname. NOTE: Do not include protocol name, port number, or domain name in the pathname. The file can be a JSP file or a servlet, or any other dynamic file.

If the user follows the second syntax representation of forward action Tag, then the target file should be dynamic where jsp:param&gt; clause is used. This allows the sending of one or more name/value pairs as parameters to a dynamic file. The user can pass more than one parameter to the target file by using more than one &lt;jsp:param&gt; clause. In the above second representation, the name attribute is used to specify the parameter name and its case-sensitive literal string. The value attribute can be specified by the parameter value taking either a case-sensitive literal string or an expression that is evaluated at request time. For example:
<jsp:forward page ="exforsys.html" /> <jsp:forward page ="/example/test" /> <jsp:param name ="username" value="exforsys" /> </jsp:forward> &nbsp;

useBean action tag:

The useBean action tag is the most commonly used tag because of its powerful features. It allows a JSP to create an instance or receive an instance of a Java Bean. It is used for creating or instantiating a bean with a specific name and scope. This is first performed by locating the instance of the bean. General syntax of useBean action Tag:
<jsp:useBean id="beanInstanceName" scope="page|request|session|application" { class="package.class" | type="package.class" | class="package.class" type="package.class" | beanName="{package.class | <%= expression %>}" type="package.class" } { /> | > other elements </jsp:useBean> }

The &lt;jsp:useBean locates the instance of the bean. If the bean is not present, then the &lt;jsp:useBean&gt; instantiates it from a class. In the above syntax of useBean action Tag there are several attributes mentioned. They are: id: This refers to a variable that is case sensitive, identifying the bean within scope attribute defined. scope: This refers to the scope of the existence of bean. The default scope is page.

class: The class name is mentioned and using this bean is Instantiated. The data type to which bean must be assigned is mentioned in type. beanName: When this is specified, the bean is instantiated by the java.beans.Beans.instantiate method.
JSP is short for Java Server Pagers and is used on the server-side to generate web pages, just as we typically use PHP, ASP, ASP.NET etc. Javascript on the other hand is a script language typically used on the client-side to make those webpages 'dynamic'. Javascript and Java is two different things. Javascript was developed by Netscape; Java was developed by Sun.

JSP is a server side scripting while Javascript is as client side scripting language. JSP also connects with database to fetch up the records from the database while javascript can be used for validate the code on client side.
JSP : - java server pages. A Scripting language that is user for the development of dynamic sites. considered as one of the most secure language for web sites. it runs at the server side javaScript : - A language that runs at the client side and mainly used for the validation purpose( like form validation) and also used for making web site interactive. J2EE : - java 2 Enterprise edition. used for the Server programming. it provide functionality to deploy fault-tolerant, distributed, multi-tier Java software, based largely on modular components running on an application server. JDBC : - Java database Connectivity. it is used for making connection of a java program with database. J2SE : - java 2 Standard Edition. This language is used for the application development but not used for very large software Except javascript all others are the product of sun microsystem. one more thing : J2ME : - Java 2 Micro Edition, or Java ME, is a Java platform designed for mobile devices and embedded systems. Target devices range from industrial controls to mobile phones and set-top boxes. this is also sun micro system product

How are transactions managed in JDBC? When using JDBC, we have two options: we can either let the JDBC driver implementation handle the transaction automatically by committing the transaction right after execution of each statement, or we can handle the transaction manually by starting the transaction and then committing it when we see fit. Note that autocommit is on by default according to the JDBC specification. The following sample code shows how to manually start and commit a transaction:

view source print?

1.con.setAutoCommit(false); 2.Statement stmt = con.createStatement(); 3.stmt.executeUpdate("insert into student(field1) values (110)"); 4.// doing some other operations like sending email, performing other db operations //and finally committing the transaction. 5.con.commit();//committing the transaction and persisting the insert operation.

For the automatic transaction management we do not need to do anything because after executing each operation the transaction will commit automatically. Note that when dealing with batch operations all of the batch members will form one single transaction and either all batch members will affect the database or none of them.

JDBC transactions
A transaction is a logical unit of work. To complete a logical unit of work, several actions may need to be taken against a database. Transactional support allows applications to ensure the following:

All the steps to complete a logical unit of work are followed. When one of the steps to the unit of work files fails, all the work done as part of that logical unit of work can be undone and the database can return to its previous state before the transaction began.

Transactions are used to provide data integrity, correct application semantics, and a consistent view of data during concurrent access. All Java Database Connectivity (JDBC) compliant drivers must support transactions. Note: This section only discusses local transactions and the standard JDBC concept of transactions. Java and the native JDBC driver support the Java Transaction API (JTA), distributed transactions, and the two-phase commit protocol (2PC). All transactional work is handled at the Connection object level. When the work for a transaction completes, it can be finalized by calling the commit method. If the application aborts the transaction, the rollback method is called. All Statement objects under a connection are a part of the transaction. This means is that if an application creates three Statement objects and uses each object to make changes to the database, when a commit or rollback call happens, the work for all three statements either becomes permanent or is discarded. The commit and rollback SQL statements are used to finalize transactions when working purely with SQL. These SQL statements cannot be dynamically prepared and you should not attempt to use them in your JDBC applications to complete transactions.

JDBC auto-commit mode By default, JDBC uses an operation mode called auto-commit. This means that every update to the database is immediately made permanent. Transaction isolation levels Transaction isolation levels specify what data is visible to statements within a transaction. These levels

directly impact the level of concurrent access by defining what interaction is possible between transactions against the same target data source. Savepoints Savepoints allow the setting of "staging points" in a transaction. Savepoints are checkpoints that the application can roll back to without throwing away the entire transaction.

marshalling (and unmarshalling) is the process that is used by RMI to tranfer and pass an object between its stub and skeleton. The marshalling (and unmarshalling) process it's achieved using object serialization (and unserialization).

Explain marshalling and demarshalling.

Answer During communication between two machines through RPC or RMI, parameters are packed into a message and then sent over the network. This packing of parameters into a message is called marshalling. On the other side these packed parameters are unpacked from the message which is called unmarshalling