new formate document

7/31/2019 New Formate Document

1/103

Aspect-Oriented Race Detection in Java


2/103

ABSTRACT

In the past, researchers have developed specialized programs to aid programmers

in detecting concurrent programming errors such as deadlocks, livelocks, starvation, and data

races. In this work, we propose a language extension to the aspect-oriented programming

language AspectJ, in the form of three new pointcuts, lock(), unlock(), and maybeShared().

These pointcuts allow programmers to monitor program events where locks are granted or

handed back, and where values are accessed that may be shared among multiple Java threads.

We decide thread locality using a static thread-local-objects analysis developed by others.

Using the three new primitive point cuts, researchers can directly implement efficient

monitoring algorithms to detect concurrent-programming errors online. As an example, we

describe a new algorithm which we call RACER, an adaption of the well-known ERASER

algorithm to the memory model of Java. We implemented the new point cuts as an extension

to the Aspect Bench Compiler, implemented the RACER algorithm using this language

extension, and then applied the algorithm to the NASA K9 Rover Executive and two smaller

programs. Our experiments demonstrate that our implementation is effective in finding subtle

data races. In the Rover Executive, RACER finds 12 data races, with no false warnings. Only

one of these races was previously known.


3/103

LIST OF CONTENTS

Page N0

List of Figures viii

List of Tables ix

1. Introduction 1

1.1 Purpose 1

1.2 Scope 1

1.3 Motivation

1.3.1 Definitions 2

1.3.2 Abbreviations 2

1.3.3 Model Diagrams

1.4 Overview 6

2. Literature Survey 10

2.1 Introduction 10

2.2 History 10

2.3 Purpose 11

2.4 Requirements 11

2.5 Technology Used 12

3. System Analysis 19

3.1 Existing System 13

3.1.1 Drawbacks 20


4/103

3.2 Problem statement 20

3.3 Proposed System 21

3.3.1 Advantages 23

3.4 Feasibility Study 24

3.4.1 Economic Feasibility 24

3.4.2 Operational Feasibility 24

3.4.3 Technical Feasibility 25

3.5 Algorithm

4. System Requirements Specification 26

4.1 Introduction 26

4.2 Purpose 26

4.3 Functional Requirements 27

4.4 Non Functional Requirements 27

4.5 Hardware Requirements 28

4.6 Software Requirements 28

5. System Design 29

5.1 System Specifications 29

5.2 System Components 29

5.3 UML Diagrams 33

5.4DFD Diagrams 38

5.5 ER Diagram


5/103

6. Implementation 42

6.1 Sample Code 42

7. System Testing 50

7.1 Testing Methodologies 50

7.2 Test cases 54

7.3 Results and Discussions 61

8. Conclusion and Future Enhancements 73

8.1 Conclusion 73

8.2 Scope for Future Enhancement 73

9. References 74


6/103

LIST OF FIGURES

Figure No. Figure NamePage No

1 Fig

2

3 class diagram

4 use case diagram

5 sequence diagram

6 Collaboration diagram

7 State chart Diagram

8 Activity Diagram

9 Deployment Diagram

10 Component Diagram

11 DFD Diagram

12 SOFTWARE TESTING LIFE CYCLE

11 Fig Login Form

12 Fig Login validation Form

14 Fig Registration Form

15 Fig Registration validation Form

16

17

18

19

20

21


7/103

LIST OF TABLES

Table No. Table Name Page No

1 Positive Test case

2 Negative Test Case

3

4


8/103

1. INTRODUCTION

PROGRAMMING errors occur frequently in software systems, and therefore,

researchers have spent much effort on developing methods to detect and remove such errors aseasily and early as possible in the development process. Concurrent programs are even more

likely to suffer from programming errors as concurrent programming adds potential sources of

failure. In a concurrent program, a programmer has to make sure to avoid deadlocks, to properly

protect shared state from data races, and to protect single threads or processes from starvation.

Researchers have developed specialized static and dynamic analyses to aid programmers with

these tasks. All of these approaches share one common concern. They identify events of interest,

such as the acquisition and release of locks or the access to shared state. Static approaches

analyze the program source, while dynamic approaches analyze a trace or abstract-state

representation generated by executing the program. Up to now, most existing dynamic

approaches have used some form of low level bytecode instrumentation library to transform the

analyzed program into one that generates those events. However, such libraries, for example,

BCEL, are difficult to use and distract efforts from focusing on the more interesting algorithmic

aspects of the analyses. Researchers have recognized aspect-oriented programming as a

convenient tool to declare instrumentation at a high level of abstraction. Aspect oriented

programming allows programmers to use predicates, called point cuts, to intercept certain events

of interest at runtime. Unfortunately, in all of the current Java-based aspect-oriented

programming languages, programmers can only intercept events such as method calls, field

accesses, and exception handling. In particular, none of these languages allows programmers to

intercept events that regard the acquisition and release of locks. This precludes programmers

from implementing algorithms in Aspect J that are meant to find concurrency related

programming errors such as data races. In this work, we hence propose a novel extension to the

aspect oriented programming language Aspect J. The language extension that we propose

enhances AspectJ with three new point cuts, to make available to the programmer three

additional kinds of events: 1) the acquisition of a lock, 2) the release of a lock, and 3) the event

of reading from or writing to a field that may be shared among threads. For instance, the

following pointcut captures the event of locking on object l: lock() && args(l). A programmer

can capture the converse event of unlocking l by simply writing unlock() && args(l). Setting a


9/103

potentially shared field on an object o is captured via the pointcut set(! static *)&&target(o) &&

may be Shared(). Matching the first two pointcuts against a given program is decidable. The

problem of matching the may be Shared() pointcut is, however, generally undecidable. We

therefore compute a sound over approximation using a static thread-local-objects analysis . The

approximation assures that the pointcut matches every access to a field that is indeed shared.

Because of the over approximation, the pointcut may, however, also match accesses to fields that

are not actually shared, i.e., fields that only a single thread accesses. Using these three novel

pointcuts, programmers can easily implement bug-finding algorithms that detect errors related to

concurrency. The lock() and unlock() pointcuts allow a programmer to uniformly act on any

acquisition and release of a lock using synchronized blocks and methods in any Java program.

The programmer can use the maybeShared() point cut to gain runtime efficiency by monitoring

accesses to only those fields that may be shared among threads. To demonstrate the feasibility of

the approach, we implemented the three novel pointcuts as an extension to the Aspect Bench

Compiler. To show how programmers can use this language extension,weadapted the ERASER

race detection algorithm to Java, and implemented it using the new pointcuts. The new algorithm

is named RACER. Both ERASER and RACER detect program executions which reveal potential

for data races in the executed application. We presented a first version of the RACER algorithm

at ISSTA 2008. However, we subsequently noted1 that a large number of potential data races

that this version of RACER reported were unfortunately false warnings. The initial version of

RACER reported these false warnings because it ignored calls to Thread.start(). The improved

version of RACER that we present in this paper takes such calls into account and therefore

avoids reporting these false positives. We applied the aspects implementing the RACER

algorithm to a plan execution program for the NASA K9 rover and two other multithreaded

programs written by computer science researchers. Our results show that the algorithm is

effective in finding data races. In the NASA code, RACER found 12 races, 11 of which were

previously unknown, although extensive studies had been performed on the K9 rover code

before. In the other two programs, we found no races, which was expected because we strongly

believe that these programs are race-free. RACER reported only one false warning on these three

benchmarks. As we will show, beyond data race detection, the extension is able to support most

(if not all) other concurrency analysis algorithms, which typically analyze properties of

synchronization and field accesses. Our extension of AspectJ can capture all of Javas


10/103

synchronization primitives, and AspectJ already provides pointcuts for accessing those entities

intended to be protected by synchronization, namely, field reads and writes. The extension, for

example, will be able to support algorithms for deadlock detection , high-level data race

detection , and stale-value detection. Researchers have previously implemented all of these

algorithms using the low-level BCEL bytecode instrumentation library . Programmers could

implement such bug-detection tools much easier using AspectJ. The main contributions of this

work are:

1. a description of three novel AspectJ pointcuts, lock(), unlock(), and maybeShared(),

2. an implementation of these pointcuts in the Aspect-Bench Compiler in the case of the

maybeShared() pointcut through a static whole-program analysis,

3. an algorithm for race detection in Java, coined RACER, that improves on ERASER, and an

implementation using the three novel AspectJ pointcuts, and

4. an experiment showing that our implementation is effective in finding data races in a plan

execution program for the NASA K9 rover.

1.1 Purpose

The language extension that we propose enhances AspectJ with three new point-

cuts, to make available to the programmer three additional kinds of events:

1) The acquisition of a lock,

2) The release of a lock, and

3) The event of reading from or writing to a field that may be shared among threads.

1.2 Scope

Matching the first two pointcuts against a given program is decidable. The problem

of matching the may be Shared() pointcut is, however, generally undecidable. We therefore

compute a sound overapproximation using a static thread-local-objects analysis. Theapproximation assures that the pointcut matches every access to a field that is indeed shared.

Because of the overapproximation, the pointcut may, however, also match accesses to fields that

are not actually shared, i.e., fields that only a single thread accesses.


11/103

1.3.1 Definition.

Lamport defines an irreflexive partial ordering among events in a program execution

called happened-before, written !. Two events ei, e j of a particular execution are ordered, i.e., ei

!e j, if (1) they belong to the same thread and are ordered in the control flow of this thread, or (2)

ei and e j belong to different threads and some inter-thread synchronization (e.g., locking, thread

start or join) forced ei to occur before e j. According to Netzer and Miller , two events ei and e j

participate in a data race, if (1) the events belong to different threads, (2) the events access the

same variable, and (3) at least one event corresponds to a write and (4) the events are not ordered

according to the happened-before relation.

1.3 Motivation

Using these three novel pointcuts, programmers can easily implement bug-finding

algorithms that detect errors related to concurrency. The lock() and unlock() pointcuts allow a

programmer to uniformly act on any acquisition and release of a lock using synchronized blocks

and methods in any Java program. The programmer can use the maybeShared() pointcut to gain

runtime efficiency by monitoring accesses to only those fields that may be shared among threads.

1.3.1 Abbreviations

Module Description

The K9 Rover and Executive

The Race on ActionExecution.status

The Races on syncNum and syncNumOpt

The Races between the RuntimeExecutive,

TheExecTimer, and ExecCondChecker

The K9 Rover and Executive:

The K9 Rover is an experimental hardware platform for autonomous wheeled rovers,

targeted for the exploration of a planetary surface such as Mars. K9 was specifically used to

experiment with new autonomy software. Rovers are traditionally controlled by low-level

commands uploaded from Earth. The K9 Executive, a software module, provides a more flexible

means of commanding a rover through the use of high-level plans in a domain-specific


12/103

programming language. High-level plans can, for example, be generated by an on-board AI-

based planner. The Executive is essentially an interpreter for the plan language

The Race on ActionExecution.status

To indicate a data race on a variable status in class ActionExectution, RACER issues the

message. The ActionExecution thread and the Runtime Executive thread cause this race because

they both access status without both first acquiring a common lock. This is exactly the error

planted in the code during the original verification experiment

The Races on syncNum and syncNumOpt

We will not show the error messages from RACER for the remaining data races. The two

data racesmentioned in this section stem from an experimentperformed with the K9 Executive

(after the case study from) in order to determine how effectively a static analysis algorithm could

reduce the number of locking operations

TheExecTimer and ExecCondChecker

we show the situation between the two threads RuntimeExecutive and ExecTimer that cause

another seven data races which RACER reported on the K9 Executive. The Main thread starts

both these threads.

1.4 Overview

We have proposed a language extension to the aspect-oriented programming

language AspectJ. We extend AspectJ with three new pointcuts lock(), unlock(), and

maybeShared(). These pointcuts allow researchers to easily implement bug-finding algorithms

for errors related to concurrency. As an example, we have implemented RACER, an adaption of

the ERASER race-detection algorithm to the Java memory model. We found that, using our

AspectJ extension, we were able to implement RACER very easily, in just two aspects with a

small set of supporting classes. The RACER algorithm is different from C-based race detection

algorithms like ERASER in the way that it treats object initialization. ERASER is very forgiving


13/103

to programmers in an objects initialization phase. RACER, on the otherhand, detects and also

reports races that comprise the initialization of an object.


14/103

2. LITERATURE SURVEY

INTRODUCTION

AspectJ Compiler representation:

These approaches are characterized by the roles and obligations of programmer,

compiler, and runtime system to determine the correctness of the synchronization.

2.1 Terminology

We adopt the terminology and notation from Choi et al. A program execution is defined

as a sequence e0, . . . ,en ofevents where ei is defined as a tuple ho,f, t,L,ki:

i is a unique id.

o is the object instance (or class) that is being accessed.

fis the field variable that is accessed inside the object.

tis the thread accessing the object.

L is the set of locks being held during the access.

kis the kind of event (one of {READ,WRITE,LOCK,UNLOCK,START,JOIN}).

Events shall not only be used to model variable access, but also lock and unlock, as well as

thread start and join; for such events, the accessed field variablefis void.

2.2 Data races

A critical section is a statement sequence that should execute without

interference of other threads. The concept is useful to guarantee that access from different

threads to the same data is ordered, avoiding inconsistency and data corruption. Races are used

to characterize situations where the guarantee about non-interference of threads accessing shared

data is violated. Netzer and Miller distinguish data races that refer to unsynchronized access of

shared data and general races that are sources of nondeterminism in parallel programs in

general. Our discussion in this section focuses on data races, while Section discusses

synchronization defects related to general races.


15/103

Intuitive definition.

An intuitive definition of a data race is that different threads access the same data, at

least one access is a write, and the access events are not ordered in the flow of the

execution.

Static detection. The set of data races that are possible by the nature of a program (i.e., all

possible executions) is calledfeasible data races . In an ideal world, one would like to define

and detect precisely the feasible data races based on a static program representation ( static

detection). The multitude of patterns and mechanisms for data sharing and thread

synchronization make it however difficult to conceive such a data race definition that matches

the intuitive concept. The following results from complexity and computability analysis show

that a precise analysis of the synchronization structure in concurrent programs is computationally

intractable or even impossible: Taylor shows that various synchronization-sensitive analyses

(those that consider only the possible interleavings and execution paths of a parallel program

with rendezvous style synchronization) are NP-complete for programs without procedures and

recursion. Ramalingam extends this result for programs with (recursive) procedures and shows

that any context-sensitive, synchronization-sensitive static analysis is undecidable. Hence,

practical static data race checkers provide an approximation and have the potential of covering

all feasible data races however at the risk of reporting incidents that do not correspond to

feasible program executions (overreporting, spurious data races); the reports of such a static tool

are called apparent races. illustrates the conceptual relationship between data races and the

findings of a typical static detection mechanism; the extent of the boxes does not reflect the

multitude of incidents or reports.

2.2. DATA RACES

According to, an ideal static checker should have the following properties:

Soundness. A sound checker reports an error if there is some error in the program (no

underreporting). Not all errors need to be reported according to this definition, e.g., a race

detection tool is still sound if it omits reports of races that are a consequence of another race.

Completeness. A checker that is complete reports only genuine errors, not spurious incidents

(no overreporting).


16/103

Dynamic detection.

Due to the difficulty of defining and analyzing data races based on a program

representation, common data race definitions and detection mechanism have focused

on program executions. An actual data race is the occurrence of a data race in a program

execution.Dynamic detection determines actual data races. Current techniques of dynamic

data race detection are afflicted with two sources of inaccuracy: Underreporting means that

actual races are omitted in the reporting (omitted data race); overreporting means that there are

reports that do not correspond to real data races (spurious data race); illustrates this discrepancy

between reported and actual respectively feasible data races. We discuss three important variants

of data race definitions that are relevant in this dissertation. The definitions differ in their

approximation of ordering among execution events and in the granularity of data that is

subsumed by an access event. For each data race definition, static and dynamic detection

mechanisms are presented and assessed according to their accuracy and runtime efficiency.

2.2.1 Happened-before data races

Definition. Lamport defines an irreflexive partial ordering among events in a program

execution called happened-before, written !. Two events ei, e j of a particular execution are

ordered, i.e., ei !e j, if (1) they belong to the same thread and are ordered in the control flow of

this thread, or (2) ei and e j belong to different threads and some inter-thread synchronization

(e.g., locking, thread start or join) forced ei to occur before e j. According to Netzer and Miller ,

two events ei and e j participate in a data race, if (1) the events belong to different threads, (2) the

events access the same variable, and (3) at least one event corresponds to a write and (4) the

events are not ordered according to the happened-before relation.

Detection. There are basically two implementation alternatives for dynamic data race detection:

Trace-based techniques record relevant events at runtime and determine data races during an

offline analysis of the execution trace. Online techniques limit the amount of trace data and

verify conditionat runtime. Due to the limited context for inferring the happened-before relation

(only a limited window of access events can be tracked by an online checker), online techniques

are usually less precise than trace-based systems; moreover, the temporal ordering of access

events is approximated through the occurrence of synchronization events at runtime, which


17/103

introduces scheduling dependence into the detector and might lead to omitted reports. An

important approach to improve the accuracy of online checkers for programs with lock-based

synchronization has been proposed in and has led to the lock-based definition of data races.

Besides accuracy, the execution overhead of online checkers, which is typically a factor of 5 to

100 of the original execution, is a major concern. Mellor-Crummey uses compile-time

information to avoid unnecessary checking of accesses to thread-local data in Fortran programs.

Christiaens and de Bosschere have investigated object-oriented programs and avoid the checking

of accesses to objects that are reachable only from a single thread; in their system,object

reachability with respect to threads is determined dynamically. Compiler optimizations

2.2. DATA RACES

and runtime tuning improve the overhead of online happened-before data race checkers to a

factor of 2 to 20.

2.2.2 Lock-based data races

The difficulty to infer the happened-before relation from a program execution has led to

another definition of data races that is not based on the temporal ordering of events but on a

lockingpolicy. The rationale behind unique-lock data races is that accesses to shared mutable

variables that are consistently protected by a unique lock cannot be involved in a data race.

Definition. LetE(o,f) be the set of events that access fieldfon object o. A unique-lock data

race on the variable o.fis defined as

uniqueLockRace(o,f) , 9ei,e j 2E(o,f) : ei.t6= e j.t^ (2.2)

9ei 2E(o,f) : ei.a = WRITE^

\e2E(o,f)e.L = /0.

This data race definition is suitable for programs that base their synchronization on locks and

monitors which is common for object-oriented parallel programs. characterizes a conservative set

of actual data races in a program execution: A complete set of access events to the same variable

that are not ordered through monitor style synchronization is identified; there could be over

reporting because the events might be ordered through other means of synchronization. This

definition is however not practical, because several common and correct synchronization patterns

violate the locking policy: initialization without lock, shared read-only data, and read-write


18/103

locks. Consequently, implementations that check for unique lock data races extend the unique-

lock data race definition and delay the checking of the locking policy, until a variable is accessed

by a second thread. This extension might lead to underreporting because the thread scheduler

could arrange the access events of different threads such that the data race is hidden; the

technique is however frequently applied in practice because it has been demonstrated that the

risk of underreporting is low and worthwhile in the light of a significant reduction of spurious

reports. The implementation of the more practical locking policy associates a locksetand state

with each variable. The state specifies if the variable has been accessed by more than one thread

(shared) and whether the second thread performed a write; the lockset records the locks that

have been held during all access and is initialized as soon as a variable is accessed by more than

one thread. At every access e, the lockset associated with variable is refined through intersection

with set of locks e.L held during e. A report is generated if the lockset got empty, if the variable

is in the shared state, and a write has been seen since the variable has become shared. Detection.

The original implementation of a lock-based data race detection (Eraser) is based on a binary

instrumentation of all memory access instructions that may target global or heap memory; this

instrumentation causes slow down by factor of 10 and 30. Subsequent research has developed

systems that exploit program analysis to reduce the amount of instrumentation and the runtime

overhead. A significant improvement has been achieved by our early work on object race

detection that used a simple escape analysis to reduce the program instrumentation and caused a

runtime overhead of 16% to 129%. A further improvement in efficiency is achieved by Choi et.

al.; their system actually checks for a refined version of unique-lock data races (common-lock

data races ) and uses several static and dynamic techniques to reduce the overhead of dynamic

data race detection for typical Java programs below 50%. One importants part of the system is

the static data race detection that we discuss, along with other static analyses for race detection.

2.2.3 Object races

The data race definitions in previous sections defined the granularity of the detection

as the smallest memory-coherent unit or individual variable. Object (data) races coarsen the

granularity of this view for object-oriented programs and define locations as objects. This is

justified because the fields of shared objects are typically accessed in the same locking context.


19/103

The coarsening of the memory granularity in the view of the checker enables runtime

optimizations that reduce the frequency of dynamic checks.

Definition. LetE(o) be the set of events that access some field on object o. Object races are

defined as a variant of unique-lock data races:

objectRace(o) , 9ei,e j 2E(o) : ei.t6= e j.t^ (2.3)

9ei 2E(o) : ei.a = WRITE^

\e2E(o)e.L = /0.

Detection. We describe and evaluate the system for object race detection in detail in Section 7.

Conclusion

The data race definitions identify a conservative set of actual data races in a program

execution. The definitions are however not operational, i.e., some of the predicates must be

approximated from the observations in an execution trace. This can lead to overreporting.

Practical mechanisms for data race detection use heuristics to assess the ordering among

accesses. The heuristics may err (even if this is uncommon) and introduce hence unsoundness:

Potential of underreporting is accepted in favor of a significant reduction of spurious reports that

would be given if a conservative approximation of access ordering was used. Two important

sources of inaccuracy of dynamic data race checkers are (1) their approximation of the temporal

ordering relation (happened-before based checkers) and (2) the delayed checking until some data

is accessed by more than one thread (unique-lock and object race checkers). illustrates the

detection capabilities of different techniques for dynamic data race checking. None of the

approaches covers all actual data races, and all approaches have the potential of overreporting.

The choice of data race definition and the design of the dynamic checker should be adjusted to

the synchronization mechanisms that are used in a program. Generally, happened-before based

techniques are preferable for programs with post-wait, rendez-vous, or fork-join style

synchronization; lock-based detectors are more appropriate for programs with monitor style

synchronization. Static data race detection can provide a conservative approximation of feasible

data races in a program and is hence useful to narrow the scope of dynamic detection

mechanisms. The use of data races as a correctness criterion for programs or program executions


20/103

is not attractive in practice due to the absence of a precise detection mechanism.

2.3 Violations of atomicity

Synchronization is not only used to prevent data races at the level of individual

variables but also used to ensure non-interference for an access sequence. Access statements that

ought to execute atomically form a critical section that can be understood as a macro-statement

in theview of a thread scheduler. Critical sections as a unit execute atomically but, like

statements, without order. Netzer and Miller refer to this phenomenon, which is the principal

source of non-determinism in concurrent programs, as general race. If critical sections are too

finegrained, undesired interference on shared data can occuralthough there is no data race.

Definition. A method is atomic if the effect of its execution is independent of the effects of

concurrent threads. In particular, shared data that is accessed by a thread tin the dynamic scope

of a method m must not be updated by concurrent threads as long as texecutes m.

Examples. Consider the example of a bank account in Program 2.3: The shared variable

balance is accessed under common lock protection and hence there is no data race. The structure

of locking specifies that the lock associated with the Account instance protects eithera read ora

write of field balance. Method update applies this synchronization discipline, however it

performs a read anda write and hence cannot be atomic. A lost-update problem can occur if

multiple threads access an Account instance and execute method update, which is itself not a

critical section, concurrently. Program 2.4 shows the example of a data structure that has atomic

methods but includes a potential data race on variable size. Programs 2.3 and 2.4 demonstrate

that the properties of race freedom and atomicity are incomparable.

2.4 Deadlock

Definition. A (resource) deadlocksituation occurs at runtime if threads use synchronization

so that a mutual wait condition arises. Some deadlock definitions are more general and consider

any situation without progress, e.g., the awaiting of an external communication interaction,

as deadlock. Our focus is on resource deadlock.


21/103

Detection. Dependencies among processes and resources can be modeled in a bipartite

resource allocation graph. Nodes correspond to processes and exclusive resources, edges from

processes to resources stand for a wait-for relation, and edges between resources and processes

represent current-use relations. The basic principle of dynamic deadlock detection is to record

and update such a graph at runtime. If the graph becomes cyclic, a deadlock is detected.

Variations of this simple algorithm have been developed for distributed systems where a unique

global view of the system in a resource allocation graph is difficult to determine and maintain at

runtime. In Java, resource deadlock can occur through mutual dependencies among threads in the

usage of locks. Recent Java runtime environments track the monitor ownership of threads in a

data structure that resembles the resource allocation graph and determine deadlock through cycle

detection.We describe and evaluate a static technique to detect potential resource deadlock in

Chapter.

2.5 Trails to correct synchronization

This section discusses different development approaches of concurrent software. First, we

categorize the approaches and discuss their strategies to address the problem of synchronization

defects. Second, we argue about the correctness criteria that are applicable to assess correct

synchronization in each approach. Third, we emphasize and discuss the approach that is

pursued in this dissertation.

Canonical approaches.

Figure 2.4 illustrates canonical approaches along their flexibility to express synchronization

patterns and their susceptibility to synchronization defects. (A) In the programmer-centric

approach, the programmer is exposed to a variety of language features that allow to explicitly

control multi-threading and synchronization. The correct application of these features is left to

the programmer. While this approach offers the widest flexibility in the design of concurrent

systems, it has important shortcomings: Compiler and runtime technology are mostly adopted

from sequential environments such that tools that assess concurrency and synchronization

defects are not integrated in them development process. The debugging of synchronization

defects is mostly done with conventional techniques. The programmer-centric approach is

current practice for the development of multi-threaded Java and C] applications today.

(B) The compiler and runtime controlledapproach offers the same flexibility for the programmer


22/103

in the use of concurrency features as the programmer-centric approach. However, the compiler

and runtime system reason about the structure of parallelism and synchronization, and determine

potential synchronization defects. For the example of data races, the assessment through the

compiler can lead to three situations: (1) The report of the compiler reflects an actual

synchronization defect that is corrected by the programmer. (2) The compiler issues a report that

is identified as benign by the programmer. The programmer communicates the synchronization

intention through an annotation to the compiler, which in turn relaxes its rules for checking in

this situation. (3) The compiler report is ignored by the programmer and a dynamic checker

determines the occurrence of synchronization defect at runtime. (C) In the language-centric

approach, certain classes of synchronization defects (data races, deadlock) are ruled out by the

design of the type system. Examples are the programming language Guava, and type extensions

of Java like or . These languages require that the programmer specifies the synchronization

discipline explicitly through type annotations and declaration modifiers. Some systems allow to

infer a large number of annotations automatically , or provide appropriate defaults to match the

common

TRAILS TO CORRECT SYNCHRONIZATION

The language-centric approach is a promising and attractive direction to address the

problem of synchronization defects. However, these systems force the software designer to use

the synchronization models that can be type-checked, and some popular and efficient, lock-free

synchronization patterns are not accommodated.1 In addition, it is unclear if the specific locking

discipline that is imposed by the type system and requires, e.g., lock protection for access to all

potentially shared mutable data structures, is well amenable to program optimization and high

performance in concurrent software systems. Hence it will be a while until language-centric

approaches to concurrency control become widely accepted.

(D) In the synthesized approach, the view of the programmer is confined to sequential

programming and parallelism is automatically synthesized through the compiler. Such

autoparallelizing compilers employ dependence analysis, discover computations without data

interference that can be executed concurrently, and finally generate efficient parallel programs.

Vectorization, e.g., has been successful along this procedure: Vectorizing compilers typically

focus on loops and exploit concurrent execution features of synchronous processor architectures


23/103

(SIMD). The transfer of auto-parallelization to asynchronous multiprocessors (MIMD) has

however brought new challenges. Parallel execution is done in separate threads, and current

hardware and OS systems cause a critical overhead in managing threads and shared data. The

focus on loops is often not sufficient and compilers are compelled to unveil new opportunities

and larger scopes for parallel execution. For object-oriented programs, dependence analysis is

complicated through the use of dynamic data structures and the effects of aliasing. Hence

speculative approaches have been conceived that can be successful to improve the performance

of programs where static dependence analysis fails. The synthesized approach to parallelism is

conceptually appealing because synchronization defects cannot occur by design. The challenges

posed through modern processor architectures and applications are however hard and manifold.

Hence automated or speculative parallelization are often not as effective as techniques where

parallelism is specified explicitly by the programmer. The scope of the dependence analysis and

speculation is usually limited to local program constructs, and hence automated parallelization is

not successful for programs where independent computational activities can be separated at

a high-level in the system design. Kennedy argues that ... it is now widely believed that (auto-

)parallelization, by itself, is not enough to solve the parallelprogramming problem.

Correct synchronization. We have presented three important classes of synchronization defects

(data races, violations of atomicity, and deadlock). Based on their definitions, we would like to

conclude with a notion of correctness for parallel programs that reflects the absence of such

synchronization defects. For the synthesizedapproach (D), the correctness criterion is to preserve

the semantics of the initial sequential program. The presence of data races or atomicity violations

is an implementation aspect. In the language-centric approach (C), correctness criteria are

explicitly stated by the programmer and verified by the type checker. Most type systems focus on

specific synchronization defects, and hence the scope of the check is limited, e.g., to the absence

of data races and deadlock.

For theprogrammer-centric (A) and the compiler- and runtime controlled(B) approach, a

precise notion of correctness is difficult to achieve: First, there is no explicit definition of the

synchronization discipline in a program, and the structure of synchronization is generally

difficult to determine from the program text. Current object-oriented programming languages


24/103

like Java and C], e.g., offer low-level features that allow for a large variety of inter-thread

synchronization mechanism; such mechanisms and their synchronization effect are not easily

recognized by a static analysis. Second, the given definitions do not allow to draw a clear line

between benign and harmful incidents: The different detection mechanisms of data races have

incomparable reporting capabilities that are neither sound nor complete. These aspects make

the three classes of synchronization defects a guideline rather than a correctness criterion.

Compiler and runtime controlled concurrency. This dissertation pursues the compiler and

runtime controlled approach to concurrency. The approach is founded on a cooperation of

programmer, compiler, and runtime system; the roles and challenges of the individual

participants respectively constituents are discussed in the following:

Theprogrammerspecifies parallelism and synchronization explicitly, and preferably follows

certain synchronization patterns that are recognized by the compiler. In cases where the compiler

is unable to infer the intention of the programmer, the programmer can provide annotations (e.g.,

type modifiers like final or volatile) to avoid unnecessary conservatism in the downstream tool

chain (compiler and runtime).

The compiler analyzes the program and reports potential incidents for different classes of

synchronization defects. The challenges are to avoid underreporting, and at the same time to

minimize the number of false positives due to conservatism. Reports presented to the user should

be aggregated and concisely specify the class and source of the problem.

The runtime system is responsible to check residual cases of potential faults that are not

resolved by the programmer. The challenge is to avoid underreporting while making the checker

efficient.

2.5 Technology Used

General

A programming tool or software tool is a program or application that software

developers use to create, debug, maintain, or otherwise support other programs and applications.

The term usually refers to relatively simple programs that can be combined together to

accomplish a task. The Chapter describes about the software tool that is used in our project.


25/103

Java Technology

Initially the language was called as oak but it was renamed as Java in 1995. The

primary motivation of this language was the need for a platform-independent (i.e., architecture

neutral) language that could be used to create software to be embedded in various consumer

electronic devices.

Java is a programmers language.

Java is cohesive and consistent.

Except for those constraints imposed by the Internet environment, Java gives the

programmer, full control.

Finally, Java is to Internet programming where C was to system programming.

Importance of Java to the Internet

Java has had a profound effect on the Internet. This is because; Java expands the Universe of

objects that can move about freely in Cyberspace. In a network, two categories of objects are

transmitted between the Server and the Personal computer. They are: Passive information and Dynamic

active programs. The Dynamic, Self-executing programs cause serious problems in the areas of Security

and probability. But, Java addresses those concerns and by doing so, has opened the door to an exciting

new form of program called the Applet.

Java can be used to create two types of programs

App li ca t io ns and App le ts : An application is a program that runs on our Computer under

the operating system of that computer. It is more or less like one creating using C or C++. Javas ability to

create Applets makes it important. An Applet is an application designed to be transmitted over the

Internet and executed by a Javacompatible web browser. An applet is actually a tiny Java program,

dynamically downloaded across the network, just like an image. But the difference is, it is an intelligent

program, not just a media file. It can react to the user input and dynamically change.

Features of Java Security

Every time you that you download a normal program, you are risking a viral

infection. Prior to Java, most users did not download executable programs frequently, and those

who did scan them for viruses prior to execution. Most users still worried about the possibility of


26/103

infecting their systems with a virus. In addition, another type of malicious program exists that

must be guarded against. This type of program can gather private information, such as credit card

numbers, bank account balances, and passwords. Java answers both these concerns by providing

a firewall between a network application and your computer.

When you use a Java-compatible Web browser, you can safely download Java applets without

fear of virus infection or malicious intent.

Portability

For programs to be dynamically downloaded to all the various types of platforms

connected to the Internet, some means of generating portable executable code is needed .As you

will see, the same mechanism that helps ensure security also helps create portability. Indeed,

Javas solution to these two problems is both elegant and efficient.

The Byte code

The key that allows the Java to solve the security and portability problems is that the

output of Java compiler is Byte code. Byte code is a highly optimized set of instructions

designed to be executed by the Java run-time system, which is called the Java Virtual Machine

(JVM). That is, in its standard form, the JVM is an interpreter for byte code.

Translating a Java program into byte code helps makes it much easier to run a program

in a wide variety of environments. The reason is, once the run-time package exists for a given

system, any Java program can run on it.

Although Java was designed for interpretation, there is technically nothing about Java

that prevents on-the-fly compilation of byte code into native code. Sun has just completed its Just

In Time (JIT) compiler for byte code. When the JIT compiler is a part of JVM, it compiles byte

code into executable code in real time, on a piece-by-piece, demand basis. It is not possible tocompile an entire Java program into executable code all at once, because Java performs various

run-time checks that can be done only at run time. The JIT compiles code, as it is needed, during

execution.


27/103

Java Virtual Machine (JVM)

Beyond the language, there is the Java virtual machine. The Java virtual machine

is an important element of the Java technology. The virtual machine can be embedded within a

web browser or an operating system. Once a piece of Java code is loaded onto a machine, it is

verified. As part of the loading process, a class loader is invoked and does byte code verification

makes sure that the code thats has been generated by the compiler will not corrupt the machine

that its loaded on. Byte code verification takes place at the end of the compilation process to

make sure that is all accurate and correct. So byte code verification is integral to the compiling

and executing of Java code.

Overall Description

Picture showing the development process of JAVA Program

Java programming uses to produce byte codes and executes them. The first box indicates that the

Java source code is located in a. Java file that is processed with a Java compiler called javac. The

Java compiler produces a file called a. class file, which contains the byte code. The .Class file is

then loaded across the network or loaded locally on your machine into the execution

environment is the Java virtual machine, which interprets and executes the byte code.

Java Architecture

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 is then interpreted on each platform by the run-time environment. Java is a

dynamic system, able to load code when needed from a machine in the same room or across the

planet.

Compilation of code

When you compile the code, the Java compiler creates machine code (called byte

code) for a hypothetical machine called Java Virtual Machine (JVM). The JVM is supposed to

execute the byte code. The JVM is created for overcoming the issue of portability. The code is


28/103

written and compiled for one machine and interpreted on all machines. This machine is called

Java Virtual Machine.

Compiling and interpreting Java Source Code

During run-time the Java interpreter tricks the byte code file into thinking that it is running on a

Java Virtual Machine. In reality this could be a Intel Pentium Windows 95 or SunSARC station

running Solaris or Apple Macintosh running system and all could receive code from any

computer through Internet and run the Applets.

Simple

Java was designed to be easy for the Professional programmer to learn and to use

effectively. If you are an experienced C++ programmer, learning Java will be even easier.

Source

Code

..

..

PC Compiler

Macintosh

SPARC

Java

Byte code

(Platform

Java

Interpreter

Java

Interpreter

Java

Interpreter


29/103

Because Java inherits the C/C++ syntax and many of the object oriented features of C++. Most

of the confusing concepts from C++ are either left out of Java or implemented in a cleaner, more

approachable manner. In Java there are a small number of clearly defined ways to accomplish a

given task.

Object-Oriented

Java was not designed to be source-code compatible with any other language. This allowed

the Java team the freedom to design with a blank slate. One outcome of this was a clean usable,

pragmatic approach to objects. The object model in Java is simple and easy to extend, while

simple types, such as integers, are kept as high-performance non-objects.

Robust

The multi-platform environment of the Web places extraordinary demands on a

program, because the program must execute reliably in a variety of systems. The ability to create

robust programs was given a high priority in the design of Java. Java is strictly typed language; it

checks your code at compile time and run time.

Java virtually eliminates the problems of memory management and de-allocation, which is

completely automatic. In a well-written Java program, all run time errors canand shouldbe

managed by your program.

Servlets and Jsp

Java Servlet technology and JavaServer Pages (JSP pages) are server-side

technologies that have dominated the server-side Java technology market; they've become the

standard way to develop commercial web applications. Java developers love these technologies

for myriad reasons, including: the technologies are fairly easy to learn, and they bring the Write

Once, Run Anywhere paradigm to web applications. More importantly, if used effectively by

following best practices, servlets and JSP pages help separate presentation from content. Best

practices are proven approaches for developing quality, reusable, and easily maintainable

servlet- and JSP-based web applications. For instance, embedded Java code (scriptlets) in


30/103

sections of HTML documents can result in complex applications that are not efficient, and

difficult to reuse, enhance, and maintain. Best practices can change all that.

In this article, I'll present important best practices for servlets and JSP pages; I assume that you

have basic working knowledge of both technologies. This article:

Presents an overview of Java servlets and Java Server pages (JSP pages)

Provides hints, tips, and guidelines for working with servlets and JSP pages

Provides best practices for servlets and JSP pages

Overview of Servlets and JSP Pages

Similar to Common Gateway Interface (CGI) scripts, servlets support a request andresponse programming model. When a client sends a request to the server, the server sends the

request to the servlet. The servlet then constructs a response that the server sends back to the

client. Unlike CGI scripts, however, servlets run within the same process as the HTTP server.

When a client request is made, the service method is called and passed a request and

response object. The servlet first determines whether the request is a GET or POST operation. It

then calls one of the following methods: doGet or doPost. The doGet method is called if the

request is GET, and doPost is called if the request is POST. Both doGet and doPost take request

and response

In the simplest terms, then, servlets are Java classes that can generate dynamic HTML

content using print statements. What is important to note about servlets, however, is that they

run in a container, and the APIs provide session and object life-cycle management?

Consequently, when you use servlets, you gain all the benefits from the Java platform, which

include the sandbox (security), database access API via JDBC, and cross-platform portability of

servlets.

JavaServer Pages (JSP)

The JSP technology--which abstracts servlets to a higher level--is an open, freely

available specification developed by Sun Microsystems as an alternative to Microsoft's Active


31/103

Server Pages (ASP) technology, and a key component of the Java 2 Enterprise Edition (J2EE)

specification. Many of the commercially available application servers (such as BEA WebLogic,

IBM WebSphere, Live JRun, Orion, and so on) support JSP technology.

How Do JSP Pages Work?

A JSP page is basically a web page with traditional HTML and bits of Java code. The

file extension of a JSP page is .jsp rather than .html or .htm, which tells the server that this page

requires special handling that will be accomplished by a server extension or a plug-in.

When a JSP page is called, it will be compiled (by the JSP engine) into a Java servlet. At this

point the servlet is handled by the servlet engine, just like any other servlet. The servlet engine

then loads the servlet class (using a class loader) and executes it to create dynamic HTML to be

sent to the browser, as shown in Figure 1. The servlet creates any necessary object, and writes

any object as a string to an output stream to the browser.

Figure 1: Request/Response flow calling a JSP page

The next time the page is requested, the JSP engine executes the already-loaded servlet unless

the JSP page has changed, in which case it is automatically recompiled into a servlet and

executed.


32/103

Best Practices

In this section, I present best practices for servlets and particularly JSP pages. The

emphasis on JSP best practices is simply because JSP pages seem to be more widely used

(probably because JSP technology promotes the separation of presentation from content). One

best practice that combines and integrates the use of servlets and JSP pages is the Model View

Controller (MVC) design pattern, discussed later in this article.

Don't overuse Java code in HTML pages:

Putting all Java code directly in the JSP page is OK for very simple applications. But

overusing this feature leads to spaghetti code that is not easy to read and understand. One way to

minimize Java code in HTML pages is to write separate Java classes that perform the

computations. Once these classes are tested, instances can be created.

Choose the right include mechanism:

Static data such as headers, footers, and navigation bar content is best kept in separate files

and not regenerated dynamically. Once such content is in separate files, they can be included in

all pages using one of the following include mechanisms:

Include directive:

Include action:

The first include mechanism includes the content of the specified file while the JSP page is

being converted to a servlet (translation phase), and the second include includes the response

generated after the specified page is executed. I'd recommend using the include directive, whichis fast in terms of performance, if the file doesn't change often; and use the include action for

content that changes often or if the page to be included cannot be decided until the main page is

executed. Another include mechanism is the action tag provided by the JavaServer pages

Standard Tag Library (JSTL). You can use this tag to bring in, or import, content from local and

remote sources. Here are some examples:


33/103

Don't mix business logic with presentation:

For advanced applications, and when more code is involved, it's important not to mix

business logic with front-end presentation in the same file. However, production JSP code should

be limited to front-end presentation. So, how do you implement the business logic part? That is

where JavaBeans technology comes into play. This technology is a portable, platform-

independent component model that lets developers write components and reuse them

everywhere. In the context of JSP pages, JavaBeans components contain business logic that

returns data to a script on a JSP page, which in turn formats the data returned from the JavaBeans

component for display by the browser. A JSP page uses a JavaBeans component by setting and

getting the properties that it provides. The benefits of using JavaBeans components to augment

JSP pages are:

1. Reusable components: Different applications will be able to reuse the

components.

2. Separation of business logic and presentation logic: You can change the way data

is displayed without affecting business logic. In other words, web page designers

can focus on presentation and Java developers can focus on business logic.

3. Protects your intellectual property by keeping source code secure.

If you use Enterprise JavaBeans (EJBs) components with your application, the

business logic should remain in the EJB components which provide life-cycle management,

transaction support, and multi-client access to domain objects (Entity Beans). Please refer to the

Enterprise BluePrintsfor further details on this.

Use custom tags:

Embedding bits of Java code (or scriptlets) in HTML documents may not besuitable for all HTML content developers, perhaps because they do not know the Java language

and don't care to learn its syntax. While JavaBeans components can be used to encapsulate much

of the Java code, using them in JSP pages still requires content developers to have some

knowledge of Java syntax.

JSP technology allows you to introduce new custom tags through the tag library facility. As a
http://www.oracle.com/technetwork/java/enterprise-141773.htmlhttp://www.oracle.com/technetwork/java/enterprise-141773.htmlhttp://www.oracle.com/technetwork/java/enterprise-141773.html


34/103

Java developer, you can extend JSP pages by introducing custom tags that can be deployed and

used in an HTML-like syntax. Custom tags also allow you to provide better packaging by

improving the separation between business logic and presentation logic. In addition, they provide

a means of customizing presentation where this cannot be done

Some of the benefits of custom tags are:

They can eliminate scriptlets in your JSP applications. Any necessary parameters to the tag can

be passed as attributes or body content, and therefore no Java code is needed to initialize or set

component properties. They have simpler syntax. Scriptlets are written in Java code, but custom

tags can be used in an HTML-like syntax.

They can improve the productivity of nonprogrammer content developers, by allowing them to

perform tasks that cannot be done with HTML.

They are reusable. They save development and testing time. Scriptlets are not reusable, unless

you call cut-and-paste "reuse."

The following programming guidelines are handy when writing custom tag libraries:

Keep it simple: If a tag requires several attributes, try to break it up into several tags.

Make it usable: Consult the users of the tags (HTML developers) to achieve a high degree of

usability.

Do not invent a programming language in JSP pages: Do not develop custom tags that allow

users to write explicit programs.

Try not to re-invent the wheel: There are several JSP tag libraries available, such as the JakartaTaglibs Project. Check to see if what you want is already available.

Do not reinvent the wheel: While custom tags provide a way to reuse valuable components, they

still need to be created, tested, and debugged. In addition, developers often have to reinvent the

wheel over and over again and the solutions may not be the most efficient. This is the problem


35/103

that the JavaServer Pages Standard Tag Library (JSTL) solves, by providing a set of reusable

standard tags. JSTL defines a standard tag library that works the same everywhere, so you no

longer have to iterate over collections using a scripted (or iteration tags from numerous vendors).

The JSTL includes tags for looping, reading attributes without Java syntax, iterating over various

data structures, evaluating expressions conditionally, setting attributes and scripting variables in

a concise manner, and parsing XML documents.

Use the JSTL Expression Language: Information to be passed to JSP pages is communicated using

JSP scoped attributes and request parameters. An expression language (EL), which is designed

specifically for page authors, promotes JSP scoped attributes as the standard way to

communicate information from business logic to JSP pages. Note, however, that while the EL is

a key aspect of JSP technology, it is not a general purpose programming language. Rather, it issimply a data access language, which makes it possible to easily access (and manipulate)

application data without having to use scriptlets or request-time expression values.

In JSP 1.x, a page author must use an expression to access the value of a

system, as in the following example:

An expression language allows a page author to access an object using a simplified syntax. For

example, to access a simple variable, you can use something like: And to access a nested

JavaBeans property, you would use something like:

If you've worked with JavaScript, you will feel right at home, because the EL borrows the

JavaScript syntax for accessing structured data.

Use filters if necessary: One of the new features of JSP technology is filters. If you ever come

across a situation where you have several servlets or JSP pages that need to compress their

content, you can write a single compression filter and apply it to all resources. In Java

BluePrints, for example, filters are used to provide the SignOn.


36/103

Use a portable security model: Most application servers provide server- or vendor-specific

security features that lock developers to a particular server. To maximize the portability of your

enterprise application, use a portable web application security model. In the end, however, it's all

about tradeoffs. For example, if you have a predefined set of users, you can manage them using

form-based login or basic authentication. But if you need to create users dynamically, you need

to use container-specific APIs to create and manage users. While container-specific APIs are not

portable, you can overcome this with the Adapter design pattern.

Use a database for persistent information: You can implement sessions with an Http Session

object, which provides a simple and convenient mechanism to store information about users, and

uses cookies to identify users. Use sessions for storing temporary information--so even if it gets

lost, you'll be able to sleep at night. (Session data is lost when the session expires or when theclient changes browsers.) If you want to store persistent information, use a database, which is

much safer and portable across browsers.

Cache content: You should never dynamically regenerate content that doesn't change between

requests. You can cache content on the client-side, proxy-side, or server-side.

Use connection pooling: I'd recommend using the JSTL for database access. But if you wish to

write your own custom actions for database access, I'd recommend you use a connection pool toefficiently share database connections between all requests. However, note that J2EE servers

provide this under the covers.

Cache results of database queries: If you want to cache database results, do not use the JDBC's

Result Set object as the cache object. This is tightly linked to a connection that conflicts with the

connection pooling. Copy the data from a ResultSet into an application-specific bean such as

Vector, or JDBC's RowSets.

Adopt the new JSP XML syntax if necessary. This really depends on how XML-compliant you want

your applications to be. There is a tradeoff here, however, because this makes the JSP more tool-

friendly, but less friendly to the developer.


37/103

Read and apply the Enterprise BluePrints: Sun's Enterprise BluePrintsprovide developers with

guidelines, patterns, and sample applications, such as the Adventure Builder and Pet Store.

Overall, the J2EE BluePrints provide best practices and a set of design patterns, which are

proven solutions to recurring problems in building portable, robust, and scalable enterprise Java

applications.

Integrating Servlets and JSP Pages

The JSP specification presents two approaches for building web applications using JSP pages:

JSP Model 1 and Model 2 architectures. These two models differ in the location where the

processing takes place. In Model 1 architecture, as shown in Figure 2, the JSP page is

responsible for processingi requests and sending back replies to clients.

Figure 2: JSP Model 1 Architecture

The Model 2 architecture, as shown in Figure 3, integrates the use of both servlets and JSP

pages. In this mode, JSP pages are used for the presentation layer, and servlets for processingi

tasks. The servlet acts as a controllerresponsible for processingi requests and creating any beans

needed by the JSP page. The controller is also responsible for deciding to which JSP page to

forward the request. The JSP page retrieves objects created by the servlet and extracts dynamic

content for insertion within a template.
http://www.oracle.com/technetwork/java/blueprints-141945.htmlhttp://www.oracle.com/technetwork/java/blueprints-141945.htmlhttp://www.oracle.com/technetwork/java/blueprints-141945.htmlhttp://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/http://www.oracle.com/technetwork/java/patterns-139816.htmlhttp://www.oracle.com/technetwork/java/patterns-139816.htmlhttp://www.oracle.com/technetwork/java/code-138808.htmlhttp://www.oracle.com/technetwork/java/code-138808.htmlhttp://www.oracle.com/technetwork/java/code-138808.htmlhttp://www.oracle.com/technetwork/java/patterns-139816.htmlhttp://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/http://www.oracle.com/technetwork/java/blueprints-141945.html


38/103

Figure 3: JSP Model 2 Architecture

This model promotes the use of the Model View Controller (MVC) architectural style design

pattern.. The Apache Struts is a formalized framework for MVC. This framework is best used for

complex applications where a single request or form submission can result in substantially

different-looking results.

Conclusion

Best practices -- which are proven solutions to recurring problems -- lead to higher quality

applications. This article presented several guidelines and best practices to follow when

developing servlet- and JSP-based web applications.

Keep an eye on servlets and JSP technologies, because several exciting things are in the works.

JavaServer Faces (JFC), for example, a Java Community Process effort that aims to define a

standard web application framework, will integrate nicely with Apache Struts.

Oracle 10g

. 10g is Oracle's grid computing product group including (among other things) a database

management system (DBMS) and an application server. In addition to supporting grid computing

features such as resource sharing and automatic load balancing, 10g products automate many

database management tasks. The Real Application Cluster (RAC) component makes it possible

to install a database over multiple servers
http://searchoracle.techtarget.com/definition/Oraclehttp://searchdatacenter.techtarget.com/definition/grid-computinghttp://searchsqlserver.techtarget.com/definition/database-management-systemhttp://searchsqlserver.techtarget.com/definition/application-serverhttp://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci214490,00.htmlhttp://searchoracle.techtarget.com/definition/Real-Application-Clusterhttp://searchoracle.techtarget.com/definition/Real-Application-Clusterhttp://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci214490,00.htmlhttp://searchsqlserver.techtarget.com/definition/application-serverhttp://searchsqlserver.techtarget.com/definition/database-management-systemhttp://searchdatacenter.techtarget.com/definition/grid-computinghttp://searchoracle.techtarget.com/definition/Oracle


39/103

Oracle Data Dictionary Concepts

The data dictionary is full of Metadata, information about what is going-on inside your

database. The data dictionary is presented to us in the form of a number of views. The dictionary

views come in two primary forms: The DBA, ALL or USER views These views are used to

manage database structures.

These views are used to monitor real time database statistics Throughout the rest of this book we

will introduce you to data dictionary views that you can use to manage your database. You will

find the entire list of Oracle Data Dictionary views documented in the Oracle documentation

online.

There are hundreds of views in the data dictionary. To see the depth of the data dictionary

views, here are the views that store data about Oracle tables:

* dba_all_tables

* dba_indexes

* dba_ind_partitions

* dba_ind_subpartitions

* dba_object_tables

* dba_part_col_statistics

* dba_subpart_col_statistics

* dba_tables

* dba_tab_cols

* dba_tab_columns

* dba_tab_col_statistics

* dba_tab_partitions

* dba_tab_subpartitions


40/103

3. SYSTEM ANALYSIS

One interesting research topic is the exploitation of users profiles and behaviour models

in the data mining process, in order to provide personalized answers. The Web mining (Kosala &

Blockeel, 2000) is a data mining process applied to the Web. Vast quantities of information are

available on the Web and Web mining has to cope with its lack of structure. Web mining can

extract patterns from data trough content mining, structure mining and usage mining. Content

mining is a form of text mining applied to Web pages. This process allows to discover

relationships related to a particular domain, co-occurrences of terms in a text, etc. Knowledge is

extracted from a Web page. Structure mining is used to examine data related to the structure of a

Web site. This process operates on Web pages hyperlinks. Structure mining can be considered

as a specialisation of Web content mining. Web usage mining is applied to usage information

such as logs files. A log file contains information related to the queries executed by users to a

particular Web site. Web usage mining can be used to modify the Web site structure or give

some recommendations to the visitor. Personalisation can also be enhanced by usage analysis

The Systems Development Life Cycle (SDLC), or Software Development Life Cycle

in systems engineering, information systems and software engineering, is the process of creating

or altering systems, and the models and methodologies that people use to develop these systems.

In software engineering the SDLC concept underpins many kinds of software development

methodologies. These methodologies form the framework for planning and controlling the

creation of an information system the software development process.

SOFTWARE MODEL OR ARCHITECTURE ANALYSIS:
http://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Information_systemshttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Methodologieshttp://en.wikipedia.org/wiki/Software_development_methodologieshttp://en.wikipedia.org/wiki/Software_development_methodologieshttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Software_development_methodologieshttp://en.wikipedia.org/wiki/Software_development_methodologieshttp://en.wikipedia.org/wiki/Methodologieshttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Information_systemshttp://en.wikipedia.org/wiki/Systems_engineering


41/103

SDLC Methodology:

This document play a vital role in the development of life cycle (SDLC) as it describes

the complete requirement of the system. It means for use by developers and will be the basic

during testing phase. Any changes made to the requirements in the future will have to gothrough formal change approval process.

SPIRAL MODEL was defined by Barry Boehm in his 1988 article, A spiral Model of Software

Development and Enhancement. This model was not the first model to discuss iterative

development, but it was the first model to explain why the iteration models.

As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase

starts with a design goal and ends with a client reviewing the progress thus far. Analysis and

engineering efforts are applied at each phase of the project, with an eye toward the end goal of

the project.

The steps for Spiral Model can be generalized as follows:

The new system requirements are defined in as much details as possible. This usually

involves interviewing a number of users representing all the external or internal users

and other aspects of the existing system.

A preliminary design is created for the new system.

A first prototype of the new system is constructed from the preliminary design. This

is usually a scaled-down system, and represents an approximation of the

characteristics of the final product.

A second prototype is evolved by a fourfold procedure:

1. Evaluating the first prototype in terms of its strengths, weakness, and risks.

2. Defining the requirements of the second prototype.

3. Planning an designing the second prototype.

4. Constructing and testing the second prototype.


42/103

At the customer option, the entire project can be aborted if the risk is deemed too

great. Risk factors might involved development cost overruns, operating-cost

miscalculation, or any other factor that could, in the customers judgment, result in a

less-than-satisfactory final product.

The existing prototype is evaluated in the same manner as was the previous prototype,

and if necessary, another prototype is developed from it according to the fourfold

procedure outlined above.

The preceding steps are iterated until the customer is satisfied that the refined

prototype represents the final product desired.

The final system is constructed, based on the refined prototype.

The final system is thoroughly evaluated and tested. Routine maintenance is carried

on a continuing basis to prevent large scale failures and to minimize down time.

ADVANTAGES:

Estimates(i.e. budget, schedule etc .) become more relistic as work progresses,because important issues discoved earlier.

It is more able to cope with the changes that are software development generally

entails.

Software engineers can get their hands in and start woring on the core of a project

earlier.


43/103

The following diagram shows how a spiral model acts like:


44/103

Fig 1.0-Spiral Model

Existing Algorithm:

PROGRAMMING errors occur frequently in software systems, and therefore,

researchers have spent much effort on developing methods to detect and remove such errors as

easily and early as possible in the development process. Concurrent programs are even more

likely to suffer from programming errors as concurrent programming adds potential sources of

failure. In a concurrent program, a programmer has to make sure to avoid deadlocks, to properly

protect shared state from data races, and to protect single threads or processes from starvation.

Researchers have developed specialized static and dynamic analyses to aid programmers with

these tasks.

Disadvantages:

Concurrent programs are even more likely to suffer from programming errors as

concurrent programming adds potential sources of failure.

Proposed System:

Matching the first two point cuts against a given program is decidable. The problem of

matching the maybe Shared() point cut is, however, generally un decidable. We therefore

compute a sound over approximation using a static thread-local-objects analysis. The

approximation assures that the point cut matches every access to a field that is indeed shared.

Because of the over approximation, the point cut may, however, also match accesses to fields

that are not actually shared, i.e., fields that only a single thread accesses. Using these three novelpoint cuts, programmers can easily implement bug-finding algorithms that detect errors related to

concurrency. The lock () and unlock() point cuts allow a programmer to uniformly act on any

acquisition and release of a lock using synchronized blocks and methods in any Java program.

The programmer can use the may be Shared() point cut to gain runtime efficiency by monitoring

accesses to only those fields that may be shared among threads. To demonstrate the feasibility of


45/103

the approach, we implemented the three novel point cuts as an extension to the Aspect Bench

Compiler. To show how programmers can use this language extension, we adapted the ERASER

race detection algorithm to Java, and implemented it using the new point cuts. The new

algorithm is named RACER. Both ERASER and RACER detect program executions which

reveal potential for data races in the executed application.

Advantages:

An additional advantage of using AspectJ is that we could easily modify the Locking

aspect to take other locking styles into account. For instance, if Reentrant- Locks were used we

could just extend the pointcuts in with an additional disjunct.

3.4 FEASIBILITY STUDY

Preliminary investigation examine project feasibility, the likelihood the system will

be useful to the organization. The main objective of the feasibility study is to test the Technical,

Operational and Economical feasibility for adding new modules and debugging old running

system. All system is feasible if they are unlimited resources and infinite time. There are aspects

in the feasibility study portion of the preliminary investigation:

Technical Feasibility

Operational Feasibility

Economical Feasibility

3.4.1 ECONOMIC FEASIBILITY

A system can be developed technically and that will be used if installed must still be

a good investment for the organization. In the economical feasibility, the development cost in

creating the system is evaluated against the ultimate benefit derived from the new systems.

Financial benefits must equal or exceed the costs.

The system is economically feasible. It does not require any addition hardware or

software. Since the interface for this system is developed using the existing resources and


46/103

technologies available at NIC, There is nominal expenditure and economical feasibility for

certain.

3.4.2 OPERATIONAL FEASIBILITY

Proposed projects are beneficial only if they can be turned out into information system.

That will meet the organizations operating requirements. Operational feasibility aspects of the

project are to be taken as an important part of the project implementation. Some of the important

issues raised are to test the operational feasibility of a project includes the following: -

Is there sufficient support for the management from the users?

Will the system be used and work properly if it is being developed and implemented?

Will there be any resistance from the user that will undermine the possible application

benefits?

This system is targeted to be in accordance with the above-mentioned issues. Beforehand,

the management issues and user requirements have been taken into consideration. So there is no

question of resistance from the users that can undermine the possible application benefits.

The well-planned design would ensure the optimal utilization of the computer resources and

would help in the improvement of performance status.

4.3 TECHNICAL FEASIBILITY

The technical issue usually raised during the feasibility stage of the investigation includes

the following:

Does the necessary technology exist to do what is suggested?

Do the proposed equipments have the technical capacity to hold the data required to use the

new system?

Will the proposed system provide adequate response to inquiries, regardless of the number or

location of users?

Can the system be upgraded if developed?

Are there technical guarantees of accuracy, reliability, ease of access and data security?


47/103

Earlier no system existed to cater to the needs of Secure Infrastructure Implementation

System. The current system developed is technically feasible. It is a web based user interface for

audit workflow at NIC-CSD. Thus it provides an easy access to the users. The databases

purpose is to create, establish and maintain a workflow among various entities in order to

facilitate all concerned users in their various capacities or roles. Permission to the users would be

granted based on the roles specified. Therefore, it provides the technical guarantee of accuracy,

reliability and security. The software and hard requirements for the development of this project

are not many and are already available in-house at NIC or are available as free as open source.

The work for the project is done with the current equipment and existing software technology.

Necessary bandwidth exists for providing a fast feedback to the users irrespective of the number

of users using the system.

3.5 Algorithm

Racer Algorithm:

when method execution accesses field f

if (f is uninitialized) {

if (f is reference field of type T) {

non-deterministically initialize f to

null

a new object of class T (with uninitialized fields)

an object created during prior field initialization (alias)

}

if (f is numeric/string field)

initialize f to a new symbolic value

}

4. SYSTEM REQUIREMENTS SPECIFICATION

4.1 INTRODUCTION

One interesting research topic is the exploitation of users profiles and behaviour models

in the data mining process, in order to provide personalized answers. The Web mining (Kosala &


48/103

Blockeel, 2000) is a data mining process applied to the Web. Vast quantities of information are

available on the Web and Web mining has to cope with its lack of structure. Web mining can

extract patterns from data trough content mining, structure mining and usage mining. Content

mining is a form of text mining applied to Web pages. This process allows to discover

relationships related to a particular domain, co-occurrences of terms in a text, etc. Knowledge is

extracted from a Web page. Structure mining is used to examine data related to the structure of a

Web site. This process operates on Web pages hyperlinks. Structure mining can be

new formate document

Documents