Is JRE alone enough for a webapp?

webapplication requires a JDK because it contains the javac compiler that is necessary in order to compile JSP (java server pages) into servlets.

Correct Exception Handling

The main challenge in writing robust JDBC code is ensuring correct exception handling. Most JDBC API methods can throw the checked java.sql.SQLException. Not only must we ensure that we catch this exception, we must ensure that cleanup occurs even if an exception is thrown.

The following code listing, which performs a trivial SELECT, shows a common JDBC error, with serious consequences:

public String getPassword(String forename) throws ApplicationException {

 String sql = "SELECT password FROM customer WHERE forename= ' " +
               forename + " ' ";

 String password = null;
 Connection con = null;
 Statement s = null;
 ResultSet rs = null;
 try {
     con = ;
   s = con.createStatement();
   rs = s.executeQuery (sql);

   while (rs.next()) {
     password = rs.getString(1);
   }
   rs. close();
   s. close();
   con.close(); 

 } catch (SQLException ex) {
   throw new ApplicationException ("Couldn't run query [" + sql + "]", ex);
 }
 return password;
}
    

Code like this can crash a whole application, and even bring down a database. The problem is that each of the highlighted lines can throw a SQLException. If this happens, we will fail to close the Connection, as the connection is closed only if we reach the last line of the try block. The result will be a "leaked" connection, stolen from the application server's connection pool. Although the server may eventually detect the problem and release the stolen connection, the impact on other users of the connection pool may be severe. Each connection costs the RDBMS resources to maintain, and pooled connections are a valuable resource. Eventually all connections in the pool may become unavailable, bringing the application server to a halt, and the application server may be unable to increase the size of the pool because the database can support no more concurrent connections.

ref : Expert One-on-One J2EE Design and Development, by Rod Johnson

Integrating JMS with EJB

JMS-EJB integration is a compelling idea. It would allow EJB components to benefit from the value proposition of messaging, such as non-blocking clients and multinary communications.

To understand the motivations behind introducing a completely different type of bean to consume messages in an EJB application, let us contemplate for a moment what other approaches could we have taken and whether they would have worked:

• Using a Java object that receives JMS messages to call EJB components. Rather than coming up with a whole new type of bean, the Java community could have promoted the idea of a Java object that can receive messages and in turn call the appropriate EJB components, such as session beans and entity beans. The problems with this approach are as follows:

  • You'd need to write special code to register yourself as a listener for JMS messages. This is a decent amount of code (as we demonstrated previously).

  • To increase the throughput of message consumption, you would have to write the multithreading logic such that you can listen to the messages on multiple threads. However, writing multithreaded applications is not a trivial task for a business application developer.

  • Your Java object that listens to messages would need some way of starting up, since it wrapped your other EJB components. If the class ran within the container, you would need to use an EJB server-specific startup class to activate your Java object when the EJB server came up. This is not portable because EJB specification does not define a standard way of activating a given logic.

  • Your plain Java object wouldn't receive any services from an EJB container, such as automatic life cycle management, clustering, pooling, and transactions. You would need to hard-code this yourself, which is difficult and error-prone.

  • You would need to hard-code the JMS destination name in your Java object. This hurts reusability, because you couldn't reuse that Java object with other destinations. If you get the destination information from a disk (such as with property files), this is a bit clunky.

• Reuse an existing type of EJB component somehow to receive JMS messages. Another option could have been to shoehorn session beans or entity beans into receiving JMS messages. Problems with this approach include:

  • Threading. If a message arrives for a bean while it's processing other requests, how can it take that message, given that EJB does not allow components to be multithreaded?

  • Life cycle management. If a JMS message arrives and there are no beans, how does the container know to create a bean

courtesy: Mastering EJB, Third Edition, Ed Roman

Single-Threaded versus Multithreaded Beans

One great benefit of EJB is you don't need to write thread-safe code. You design your enterprise beans as single-threaded components and never need to worry about thread synchronization when concurrent clients access your component. In order to service concurrent client requests, your EJB container automatically instantiates multiple instances of your component.

The container's thread services can be both a benefit and a restriction. The benefit is that you don't need to worry about race conditions or deadlock in your application code. The restriction is that some problems lend themselves well to multithreaded programming, and that class of problems cannot be easily solved in an EJB environment.

So why doesn't the EJB specification allow for multithreaded beans? EJB is intended to relieve the component developers' worry about threads or thread synchronization. The EJB container handles those issues for you by load-balancing client requests to multiple instances of a single-threaded component. An EJB server provides a highly scalable environment for single-threaded components.

If the EJB specification allowed for beans to control threads, a Pandora's box of problems would result. For example, an EJB container would have a very hard time controlling transactions if beans were randomly starting and stopping threads, especially because transaction information is often associated with a thread.

The bottom line is that EJB was not meant to be a Swiss army knife, solving every problem in existence. It was designed to assist with server-side business problems, which are largely single-threaded. For applications that absolutely must be multithreaded, EJB may not be the correct choice of distributed object architectures.

courtesy: Mastering EJB, Third Edition, Ed Roman

How Does Guaranteed Message Delivery Work?

With guaranteed message delivery, the MOM system persists your messages to a file, database, or other store. Your message resides in the persistent store until it's sent to a message consumer, and the message consumer acknowledges the consumption of the message. If the acknowledgment of a message is not received in a reasonable amount of time, the message remains on the persistent store and is redelivered.

This feature is beneficial when the message consumer is brought down on a regular basis for maintenance, and lost messages are unacceptable. This is especially true in industries, such as financial services, where messages represent securities changing hands.

A variation on the guaranteed message delivery theme is certified message delivery. Certified message delivery not only ensures the delivery of a message from a producer to a consumer, but also generates a consumption receipt that is delivered to the message originator, indicating a successful consumption of the message. Certified message delivery is used by producers to better manage communication with consumers.

Another variation of guaranteed message delivery is called store and forward. Store and forward enables a message producer to successfully send a message to an inactive MOM system. The producer transparently spools the message to a local store until the MOM system is reactivated, at which point the message is delivered to the MOM system and forwarded to any available consumers. Guaranteed message delivery without the store-and-forward option requires producers to send messages to active MOM systems, but consumers do not have to be active. Store and forward with guaranteed message delivery allows messages to be sent whether MOM systems or consumers are active or inactive.

courtesy : Mastering EJB, Third Edition, Ed Roman

obtaining user transaction of the client from inside the bean

To control transactions from client code, you must look up the JTA UserTransaction interface with the Java Naming and Directory Interface (JNDI). JNDI is a generic lookup facility for looking up resources across a network, and it is fully described in Appendix A. The following code illustrates looking up the JTA UserTransaction interface from client code using JNDI:
/*
* 3: Look up the JTA UserTransaction interface
* via JNDI. The container is required to
* make the JTA available at the location
* java:comp/UserTransaction.
*/
userTran = (javax.transaction.UserTransaction)
ctx.lookup("java:comp/UserTransaction");

Wont this collide with any other usertransaction created by other client. How is the integrity assured?

beans vs allowed transactions

Here is a brief explanation of why certain transaction attributes are disallowed. Entity beans and stateful session beans with SessionSynchronization must use transactions. The reason is that both of these types of beans are inherently transactional in nature. Entity beans perform database updates, and stateful session beans with SessionSynchronization (which we describe later in this chapter) are also transactional. Therefore you normally can't use the following attributes: Never, NotSupported, Supports. Note that the EJB specification does allow for containers to optionally support these attributes for stateful session beans and entity beans—but only if you're using non-transactional data stores—and with the warning that if you use this, your beans will not be portable, and you may find that you receive inconsistent results.

A client does not call a message-driven bean directly; rather, message-driven beans read messages off a message queue in transactions separate from the client's transaction. There is no client, and therefore transaction attributes that deal with the notion of a client's transaction make no sense for message-driven beans—namely Never, Supports, RequiresNew, and Mandatory.

halting problem (a.k.a) infinite block problem

There is a huge caveat with using container-managed transactions with JMS message-driven beans in a certain scenario. Let's say you have an EJB component (any type of component) that sends and then receives a message all within one big container-managed transaction. In this case, the send operation will never get its message on the queue, because the transaction doesn't commit until after the receive operation ends. Thus, you'll be waiting for the receive operation to complete forever. This is called the infinite block problem, also known as the halting problem in computer science.

An easy solution to this problem is after sending the request message, you can call commit() on the JMS Session, which is your JMS transaction helper object. This causes the outgoing message buffer to be flushed. Hence, the receive operation does not have to wait forever for the transaction to commit to get a message.

[ref: Mastering EJB, Third Edition, Ed Roman et al.]

do applications always need an UI

Web Service clients. Some business applications require no user interface at all. They exist to interconnect with other business partners' applications that may provide their own user interface. For example, consider a scenario where Dell Computer Corporation needs to procure Intel chips to assemble and distribute desktop computers. Here, Intel could expose an Order Parts Web Service that enables the Dell Web Service client to order chips. In this case, the Intel system does not provide a graphical user interface per se, but rather it provides a Web Service interface.

Common VI Commands used

To move to a log at the end of the file:

	^f	move forward one screen
	^b	move backward one screen
	^d	move down (forward) one half screen
	^u	move up (back) one half screen

*	u	UNDO WHATEVER YOU JUST DID; a simple toggle

*	a	append text after cursor, until hit

*	i	insert text before cursor, until hit

*	r	replace single character under cursor (no needed)
	R	replace characters, starting with current cursor position, until hit

*	x	delete single character under cursor
	Nx	delete N characters, starting with character under cursor

*	dd	delete entire current line
	Ndd or dNd	delete N lines, beginning with the current line; e.g., 5dd deletes 5 lines

	yy	copy (yank, cut) the current line into the buffer
	Nyy or yNy	copy (yank, cut) the next N lines, including the current line, into the buffer
	p	put (paste) the line(s) in the buffer into the text after the current line

	/string	search forward for occurrence of string in text
	?string	search backward for occurrence of string in text
	n	move to next occurrence of search string
	N	move to next occurrence of search string in opposite direction

MOVING

:# move to line #

:$ move to last line of file

Why Use an Embedded Database?

whenever applications provide their own database management, those databases are called embedded. In a sense, they can be seen as being embedded in the application, as well as on the local system.

At one time, databases of this kind were the norm. Consider, for example, that COBOL has built-in primitives for creating and maintaining embedded databases. These are true primitive keywords of the language, they are not even function calls. Today, FoxPro and similar languages come closest to this model. In the heyday of COBOL and xPro languages, client-server relational database management systems were not common. As a result, these languages often created local data stores, which were used by the immediate application. Later on, data records would be exported to a central database as needed.

Embedded DB in Applications
Suppose you were designing a utility like Microsoft Outlook, which provides a GUI front end for entry of appointments, contacts, and individual e-mails. How would you handle the data management of these records? Likely, you would want a database to do this for you, but you'd be in a bit of jam deciding how to choose one. The first problem is that you cannot rely on the customer having any particular database, to serve as a back-end to your software. You could compensate for this by providing a generic database front-end (say, with ODBC, JDBC, or the like) and then have the customer map it to the DBMS in use at their site. But if the customer is a consumer running your productivity suite on an occasionally connected notebook, what are you going to do? The solutions is: You provide your own DBMS in the form of an embedded database. Later, if this embedded database has to sync with another (such as Outlook synching with Microsoft Exchange or with a handheld device), you rely on application-level data import and export functions to perform this function.

Consumer-oriented software is a clear, definable market for embedded databases. Candidate applications include accounting software, portfolio tracking, and so on. Today, each of these applications comes with its own embedded data store. The best embedded databases have several traits in common: they don't consume a lot of resources, they're fast, and they are utterly reliable—three qualities that consumer products must deliver in today's highly competitive markets.

ref:
http://www.devx.com/IBMDB2/Article/27622

Spam prevention mechanism

One of the famous Spam prevention mechanism is Bayesian Filtering.
This Bayesian filtering can filter almost any kind of data but widely applied in email world to classify a spam mail.

The algorithm operates on the classic bayes theorem.
Probability that A occurs given B has occured = Probability that B occurs given A occured X probability that B occurs divided by Probability that A occurs

P(A/B) = P(B/A)x P(B) / P(A)


In email context, it is classifying that a mail is a spam based on the words in it.

Probability that these words occur in a spam mail X probability that a given mail is a spam normalised by the probability that these words can occur in a mail.

Probability that a given mail is a spam is a user specific factor : If the user rejects lot of mail as spam, he may be so picky or he really gets a lot of spam. Then this will be high for this user.

But if he gets very less probable spam mails; but what ever is put as spam contains these words; then it does not mean that this is a spam mail. Because these can be in a mail that is not a spam. So the probability of these words in any mail (denominator) checks this factor that commonly used words in all mails will not be given high weightage in rejecting a mail as spam.

Some common OO bad codes - II

The God Class Problem
Distribute system intelligence horizontally as uniformly as possible, that is, the top-level classes in a design should share the work uniformly.


Do not create god classes/objects in your system. Be very suspicious of a class whose name contains Driver, Manager, System, or Subsystem


Beware of classes that have too much noncommunicating behavior, that is, methods that operate on a subset of the data members of a class. God classes often exhibit much noncommunicating behavior.

Cure:

Divide noncommunicating behavior into separate classes

Did you ever wonder why we see this piece of code?

if(debug is enabled)
{

logDebug("xxxx.....");
}

I was wondering for a long time why it is being done?
I can control the log level at production using configuration files.
I can turn off debug level logging in the log4j or any decent loggers config files.
But still, the conditional check if(debug is enabled) is performed in any many places, which I thought absurd and redundant.

But the reason is even though the logger does not physically log; the logDebug("xxxx.....") call is actually made which checks whether to log Debug level or not. Though we also check the same what the API checks, the thing we save here is the parameter construction. If the parameters are more or built by concatenating strings, it can be costly at runtime for constructing these. Though the time to log is saved, the time for constructing these parameters is a cost to the system. Hence this check if(debug is enabled) is made to save some time.

When Would I Not Use Stored Procedures?

When Would I Not Use Stored Procedures?
Whole discussion boards have been devoted to the pro/con debate on stored procedures. But when it comes down to it, you have only a few occasions when it might not be possible or prudent to use them.

• You don't have the database permissions to create them. Or a cooperative DBA.
• You're only using a few SELECT statements in your application and can't really benefit from the performance and organizational boosts offered by stored procedures (though you might still profit from the other gifts of the stored procedure).
• Your organization is undergoing a major code migration and wants to avoid encapsulating your source in external procedures. However, this is debatable as well since you may actually benefit from the stability of SQL syntax.

ref :
http://www.devx.com/IBMDB2/Article/27818

When Do I Use Stored Procedures?

When Do I Use Stored Procedures?
Coders might argue that you never really need a stored procedure. All of your database calls can be done programmatically. That's true, but somewhat limiting. Stored procedures can do a lot of things for you that even the most elegant code cannot.

Chief among these, stored procedures save processor time by allowing you to offload database calls to the database server itself. Most databases load the compiled procedures into memory the first time they're called, or even before, dramatically reducing overhead when you're doing the same essential process multiple times (such looping operations are very common in database manipulation).

Stored procedures offer you many other benefits, as well.

• They allow you to encapsulate code. In other words, the database operation appears once, in the stored procedure, not multiple times throughout your application source. This improves debugging as well as maintainability.
• Changes to the database schema affect your source code in only one place, the stored procedure. Any schema changes then become a DBA task rather than a wholesale code revision.
• Since the stored procedures reside on the server, you can set tighter security restrictions on the client space, saving more trusted database permissions for the well-protected stored procedures themselves.
• Since stored procedures are compiled and stored outside the application, they can use more sensitive variables within the SQL syntax, such as passwords or personal data, that you would avoid using in scripts or remote calls.
• Using stored procedures greatly reduces network traffic.

As a further illustration of this last point, suppose you want to update a customer record but you're not sure if the record even exists. One way is (a) to SELECT the record to see if the customer exists, (b) to UPDATE the record if it does, and (c) to INSERT a new record if it does not.

If you just put a series of SQL statements in your client code, each line is executed by sending a message over the network to the server, usually getting a response in return. But a stored procedure resides on the server. When called from the client application, it executes on the server and only has to respond when returning the final result set to the client, saving lots of back-and-forth traffic.

One other benefit you'll find with DB2 stored procedures in particular, the distinction of which will be explained in but a moment, is the Development Tooling support. The Enterprise edition of DB2 UDB (Universal Database) ships with a set of developer tools that allow for fast, reliable creation of stored procedures in both SQL and Java. Using the Wizards and Query Builders, you can create complex procedures without typing a word of code.

ref :
http://www.devx.com/IBMDB2/Article/27818

Designing for Change - I

Designing for Change

All the patterns are required when we need our design to be flexible enough to face a change with out major impact. The Object orientation itself is just another style of programming that came up to solve many issues of the software engineering especially in the post implementation phase. Some of the fundamental principles / benefits on which the OO paradigm rode on are Reusability, Scalability, Maintainability etc. These were the goals for which the OO priciples and concepts stand for. If a system developed with a programming language that provides OO constructs does not provide the above said benefits, then it is not to be called a OO system.

The fact that you find programmers abundant in that language and you get the tools for that platform could have made it convenient to use it to build a system. But make sure if you really want to build a OO system or not before designing.

Some common design problems with design patterns that address the problem

• Creating an object by specifying a class explicitly
  
  

  Abstract factory, Factory Method, Prototype
  
  

• Dependance on specific operations
  
  

  Chain of Responsibility, Command
  
  

• Dependence on hardware and software platforms
  
  

  Abstract factory, Bridge
  
  

• Dependence on object representations or implementations
  
  

  Abstract factory, Bridge, Memento, Proxy
  
  

• Algorithmic dependencies
  
  

  Builder, Iterator, Strategy, Template Method, Visitor
  
  

• Tight Coupling
  
  

  Abstract factory, Bridge, Chain of Responsibility, Command, Facade, Mediator, Observer
  
  

• Extending functionality by subclassing
  
  

  Bridge, Chain of Responsibility, Composite, Decorator, Observer, Strategy
  
  

• Inability to alter classes conveniently
  
  

  Adapter, Decorator, Visitor

In this series we will take each problem one day and analyse how these patterns help solving them.

[ref : http://www.eli.sdsu.edu/courses/spring98/cs635/notes/patternIntro/patternIntro.html]

Some common OO bad codes - I

Heuristics Continued
Beware of classes that have many accessor methods defined in their public interface. Having many implies that related data and behavior is not being kept in one place.

class test
 {
 private int thisData;
 private int thatData;
 private float moreData;

 public void setThisData( int data )  { thisData = data; }
 public void setThatData( int data )  { thatData= data; }
 public void setMoreData( int data )  { moreData= data; }
 public void getThisData(  )  { return thisData; }
 public void getThatData(  )  { return thatData; }
 public void getMoreData(  )  { return moreData; }
 public String toString() { // code deleted }
 }

No work is being done in this class.

Other classes are getting the data in class test and performing some operation on it.

Why is this class not doing the work on the data!

Who is doing the work?

Java and the Singleton

There is a major problem using the Singleton in java

Classes in java can be garbage collected!

A class can be garbage collected when there are no objects of the class and there are no variable references to the class of the class

If the Logger class is garbage collected then the value of the Singleton will be lost

The next time you reference the Singleton you will get the default value for the Singleton

Solution
Insure that there will be a reference to the class or an instance of the class

Place an instance of the class in a global reference

private static void preventClassGarbageCollection()
    {
    Properties systemTable = System.getProperties();
    systemTable.put( "_$sdsu.logging.Logger.instance",
                                   new Logger());
   }

[ref : http://www.eli.sdsu.edu/courses/spring98/cs635/notes/logger/logger.html]

builder pattern :

director
builder
product

requires a builder who builds a product from its parts
an abstract builder builds an abstract product with some abstract processes

The director is the one who determines the parts and the sequence in which the build processes are called to build a particular type of product.
ex:

class WorkShop {
 //force the order of building process
 public void construct(HouseBuilder hb) {
     hb.buildFoundation();
     hb.buildFrame();
     hb.buildExterior();
     hb.buildInterior();
 }
}

When a new product is to be built, a new builder is created from the existing builder and it is used to build the new product. The advantage is as and when the new product emerges which changes only a specific part only the class / process which builds it can be modifiedand a new builder can be created so easily.

The client creates the Director object and configures it with the desired Builder object

Director notifies the builder whenever a part of the product should be built

Builder handles requests from the director and adds parts to the product

The client retrieves the product from the builder

ref:
http://www.javacamp.org/designPattern/
http://www.eli.sdsu.edu/courses/spring98/cs635/notes/builder/builder.html
http://unicoi.kennesaw.edu/~jbamford/csis4650/uml/GoF_Patterns/builder.htm

hmm... shame on me today... i went to office at 9:30. supervised the status of my module and component. Then i analysed my offshore delivarable. Then some one called for a team lunch to an indian restaurant. We left at 12:00 PM and then after lunch my developer instinct said it needs some rest. so I left for the day. It is an irresponsible move. I got to compensate tomorrow to overcome my guilty feeling. But i enjoyed the time in evening.

Ok. So todays lesson is:
1) Respect your work. If you know something is going to prevent you doing it, stay away from it.

Technical lesson:
I planned to use the builder pattern for a class which exceeded 3000 lines of code in java. The purpose of the class is to map a big chunk of data from the host system to Object model. The whole mapping is handled by a single class. After reading through the builder pattern yesterday, I guessed my class is an apt candidate for applying builder pattern.

* The Builder Pattern assembles a number of objects to make a new object, based on the data with which it is presented. Frequently, the choice of which way the objects are assembled is achieved using a Factory. It constructs a complex object from simple objects step by step.

My plan is to build all the composite objects by using separate builder objects and finally assemble it using a super builder object. This way, the code is more organised and more maintainable.

I am a developer. Today, I vow myself that I am going to update here daily something I learnt that day. For, I don't want to turn back after 10 years and be puzzled at what I learnt in the 10 years.
I am now puzzled looking back at my 3 years of software development.

Also I am planning to include members in this blog. So if you are interested and if you are a regular visitor of this blog, I will include you as a member so that you can post here.