Whose mistake?

        I will graduate in this December, and now looking for a job. To be honest, I really want to be a J2EE programmer.  Actually, I have had several interviews with some companies. It doesn’t matter whether I finally get a job, but I have strong feeling that what we learned in the university are not the same things the company want to get from us. When I studied for my bachelor degree in China, I had already hearded a lot of information about the knowledge we get from the classes are detached from the companies. However, now, when I am studying for the masters’ degree in U.S, I find the same thing happens here as in China.

        For example, Agile Development is so popular in most software companies currently. However, in the university, we almost have no chance of understanding it deeply, perhaps just heard a little bit informaton on it, and it is not necessary to say we cannot apply it to the real projects.

        Whose mistake is this? It is not the professors’ mistake, since they are just responible for giving instructions to students. It is absolutely not the companies’ mistake. They just want to find the right person who can contribute to the companies immediately. It is also not the students’, expecially the good students’, mistake. We spend a large part of our time in all kinds of assignments in that we want a high GPA, so that it is impossible for us to concentrate on the things which are becoming the trend.

        In fact, we cannot find the right person who need to be responsible for this problem. What we need to do is finding the reasons caused it and solving this problem. In my opinion, the most important reason is that the purposes of the unversity and the company are different from each other. The universities aim to help the students build solid foundation and form a good learning way, therefore, the students can pick up new things more quickly and effectively in the future. However, the companis hope the new employees can bring their benefits immediately. I think no company would like to invest time and money to the new employees and wait for them to bring profit, which also explains why experience is the most significant factor when somebody is looking for a job. In fact, few days ago, I read an article that some students complain that why the textbooks they use are the ones published 20 years ago, for example, the theory of operating system, which is usually a required course of the computer science department.

Shift to Dynamic programming language

        In recent years, dynamic programming languages develope very fastly, especially PHP and Ruby. There is no doubt that They have already became the first choice for many programmerers when developing web applications. Furthermore, it seems that more and more people, like thoughtworks, are trying to apply them to enterprise applications dominated by Java and C#.

        I have studied JAVA for almost 5 years. I love it. Everything in JAVA makes me comfortable. Although I have finished several projects by PHP, and in some aspects, PHP is really better than JAVA, I still put JAVA in the first place in my mind.

       In fact, there are already a lot of arguments about PHP or Ruby on Rails are not suitable for complex enterprise appliactions. In my opinion, everything in the world is changing, so is dynamic programming language. Just like Java adopts some good features of dynamic language, for example, reflection and supporting scripting language, I believe that both PHP and Ruby on Rails are developing so that they can be applied in a broader area.

        Now, I have a strong feeling that it is necessary to pay more attention to Ruby and Ruby on Rails. Many Java programers think that studying dynamic languages can imporve their thought about Java. Therefore, it is killing two birds with one stone.

        Fortunately, because I have much experience in Java, it is easy to pick up a kind of dynamic language. However, I suggest the people who want to study programming start from Java or C++, since they are more religious and can help you build solid fundation in programming.

As a Java Programmer, Do you still remember?

        Today, When I was tidying up the disk space of my hard driver, I found something interesting. It is the notes I made when I started learning Java. In fact, I have already used Java for almost 4 years. However, when I am coding, It seems that many things have already became my habits, so that I don’t think about the reason why I do it like that. When reading these notes again, I have a feeling of getting an insight into the problem. Therefore, I suggest all the programmers, not just Java programmer, not always keeping coding, sometimes please stop to think and recall.

        In the following, there are some concepts of Java. They are pretty easy, but do you still remember them?

Default values for primitive members: When a primitive data type is a member of a class, it is guaranteed to get a default value if you do not initialize it. Notice that this guarantee doesn’t apply to local variables (for example, you declare it in a method), since that are not fields of a class.

The static keyword: When you say something is static, it means that data or method is not tied to any particular object instance of that class, and it directly belongs to the class. Bear in mind that the static method cannot directly access non-static members or methods. There are two ways to refer to a static variable and method. You can name it via an object or refer to it directly through its class name. Usually, we always prefer to the later way.

Distinguishing overloaded methods: there is a siimple rule. Each overloaded method must take a unique list of argument types. Even differences in the ordering of arguments are sufficient to distinguish two methods. And only the differences of the type of return value cannot separate two methods.

String s = new String(“a String”);
this sentence contains four tasks. The first one is creating a String object in the heap; the second one is initializing this String object as “a String”; the third one is create a reference named s; then make this reference point to the String object.

what is the sequence of initializing the members of a java class?
Let’s assume that there is a class named Dog.

1. when we create an object of Dog or the first time to access the static members or methods of Dog, JVM need to find Dog.class firstly
2. all the static memebers of the Dog class will be initialized
3. arranging space for the object created by new Dog() in the heap. This space will be cleared and all the memebers of the Dog class will get their default value
4. run the definition initialization
5. run the consturctor

The differences between Decorator Pattern and Proxy Pattern

       Firstly, Let’s look at the following two UML diagrams which describes the basic implementation of Decorator Pattern and Proxy Pattern respectively.

        The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy PatteRn, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.        However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of abject inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.

       We can use another sentence to conclude thire differences: with the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively constructed at runtime.

//Proxy Pattern
public class Proxy implements Subject{

       private Subject subject;
       public Proxy(){
             //the relationship is set at compile time
            subject = new RealSubject();
       }
       public void doAction(){
             ….
             subject.doAction();
             ….
       }
}

//client for Proxy
public class Client{
        public static void main(String[] args){
             //the client doesn’t know the Proxy delegate another object
             Subject subject = new Proxy();
             …
        }
}
//Decorator Pattern
public class Decorator implements Component{
        private Component component;
        public Decorator(Component component){
            this.component = component
        }
       public void operation(){
            ….
            component.operation();
            ….
       }
}

//client for Decorator
public class Client{
        public static void main(String[] args){
            //the client designate which class the decorator decorates
            Component component = new Decorator(new ConcreteComponent());
            …
        }
}

Patterns and Refactoring – After reading the article “Patterns & XP”

   

      The article “Pattern & XP” is written by Joshua Kerievsky. The purpose of this article is to figure out how to apply Patterns to the context of Extreme Programming, because he thinks that XP has far focused heavily on Refactoring while remaining all but silent about Patterns, the reason for this is that Patterns encourage over-engineering, while Refactoring keeps things simple and light.

      The prerequisite of understanding the importance of combining patterns and refactoring is realizing the relationship between them. This article has quoted some words from the Design Patterns Book, which can help to explain it well.

     Our design patterns capture many of the structures that result from refactoring. Using these patterns early in the life of a design prevents later refactorings. But even if you don’t see how to apply a pattern until after you’ve built your system, the pattern can still show you how to change it. Design patterns thus provide targets for your refactoring.

     However, there are two problems of applying patterns early in the life of a design. The first one is over-engineering, which means that we make great efforts to produce flexible and robust designs early in the life of a system, but we do not realize that all our work will be meaningless and wasteful if the system never needs such degrees of flexibility and robutness. Sometimes, it is not necessary to inject various desgin patterns to our designs. Secondly, there is no 100% perfect design, in order to keep the system in high quality, refactorying is necessary!

     In the other side, without Patterns, refactoring may make small design improvements, but their overall design will ultimately suffer because it lacks the order, simplicity, and effectiveness that come from intelligently using Patterns.

     Herefore, Joshua Kerievsky suggest us that: start simple, think about Patterns but keep them on the back-burner, make small refactorings, and move these refactorings towards a Pattern or Patterns only when there is a genuine need for them.

Transaction Concurrency (2)

       As mentioned in the article Transaction Concurrentcy(1), most application choose read committed as the isolation level. The reason is that no matter whether there is concurrency occuring, serializable and repeatable read need to lock the rows in the database, which cause the reduction in the system performance, especially for these system where concurrency doesn’t happen frequently. However, Read committed cannot avert unrepeatable read and Second lost updates problem, therefore, we need to use optimistic locking or pessimistic locking to make up!

      Today, I am going to make a brief introduction to optimistic locking. Optimistic locking is based on the assumption that most database transaction don’t conflict with other transactions. In fact, optimistic locking doesn’t actually lock anything. Instead, when a transaction updates a row it verifies that the row has not been changed or deleted by a different transaction since it was read. If it has, the transaction is typically rolled back and retried.

     Usually, there are three methods to realize optimistic locking. The first one is adding a version column to the tables in the database. The second one is adding a timestamp column, and the third one is to compare current values of the columns with their previously read values. Commonly, we prefer the vrsion column to the other two methods, since the third method makes the sql sentences too complicated and the second method is not suitable for any case.

     There is a sql sentence using version column:
     Update ACTIVITIES Set PLACE = ‘?’ WHERE ACTIVITY_ID=? AND VERSION = ?;

     The following is an simple example to show how to configure optimistic locking realized by version column. It is pretty easy!

<hibernate-mapping>
      <class name=”**” table=”**”>
              <id name=”*” column=”*”>
                    <generator class=”*” />
              </id>
              <version name=”version” column=”VERSION” />
      </class>
</hibernate-mapping>

Transaction Concurrency (1)

       One of the big differences between Enterprise Application and Normal web application is that the enterprise applications must handle the problem of concurrency, because they are usually multiuser applications, where several transactions update the database at the same time frequently. Before we can deal with concurrency, It is useful to know more about it.

       In fact, we devide the problems caused by concurrency into several categories. They are:
        Lost Update : Two transactions both update a row and then the second transaction aborts, causing both changes to be lost.
       Dirty read : One transaction reads changes made by another transaction that hasn’t yet been committed. However, if the second transction roll back, the data the first transaction readed is not correct!
       Unrepeatable read : A transaction reads a row twice and reads different state each time. For example, another transaction may have written to the row, and committed, between the two reads.
       Second lost updates problem : A special case of an unrepeatable read. Imagine that two concurrent transactions both update arow, one writes to it and commits, and then the second writes to it and commits. The changes made by the first writer are lost. This situation is pretty similar to Lost Update, please note the differences between them.
      phantom read : A transaction executes a query twice, and the second result set includes rows that weren’t visible in the firstresult set. This situation is caused by another transactioin inserting new rows between the executions of the two queries.

     Ok, It is time to handle concurrency now. Usually, it is not a good way to serialize transactions which means make the transactions execute one by one and it will reduce the performance of the application. In fact, we define severl transaction isolation levels. They are separately:
     Read Committed : Permits unrepeatable reads but not dirty reads. Reading transactions don’t block other transactions from accessing a row. However, an uncommitted writting transaction blocks all other transactions from accessing the row.
     Repeatable read : permits neither unrepeatable reads not dirty reads. Phantom reads may occur. Reading transactions block writing transactions (but not other reading transactions), and writing transactions block all other transactions.

     In Hibernate framework, we can set the isolation for JDBC connections using a Hibernate configuration option. The defaultisolation level is repeatable read isolation whichs is represented by number 4 (Hibernate.connection.isolation = 4). 1 means read uncommitted isolation; 2 means read committed isolation; 8 means serializable isolation. In most cases, we prefer 2.

     However, it is not a good idea to let the database to deal with the concurrency by itself, we think it is the responsibility of the application to handle them. In my next article, I would like to write something about how to deal with concurrency using optimistic locking and pessimistic locking.

Is there any repeat?

       As we all know, Spring DAO is based on template method pattern. The reason why Spring DAO adopts template method pattern is that there are some setted processes before and after accessing the database, such as start and commit the transaction, open and close the database connection. Therefore, when we use Spring DAO template, for example, HibernateTemplate and JdoTemplate, we don’t need to write code for transactions by ourselves, since the DAO template will does that job for us.

       However, I has been thinking about a question , and I still not find the answer to it. Spring framework supports declaration transaction. In fact, in many projects, we use DAO template to access the database, at the same time, we also configure transaciton in spring configuration files. Therefore, is it necessary to declare transaions in spring configuration files when we already take the advantage of DAO template, which already helps us handle transactions? is it redundant for us to do that?

       In order to find the answer, I have refered to some materies. There is an explansion in spring document. It is that “even if HibernateTransactionManager is used for transaction demarcation in higher-level services, all those services above the data access layer don’t need to be Hibernate-aware. Setting such a special PlatformTransactionManager is a configuration issue: For example, switching to JTA is just a matter of Spring configuration (use JtaTransactionManager instead) that does not affect application code.”

      What is your opinion about this explanation. To be honest, It doesn’t make sense to me and it still not help me answer this question. I am sorry for my slow response. I hope you can help me solve this question! Thanks a lot!

Exposed Domain Model Pattern

       In my former articles, I have mentioned “open session in view” many times. What is open session in view? When we use Hibernate framework, the Hibernate session will be closed after a transaction being submitted. Then, when the presenter layer of a web application accesses the detached objects, it may access an unloaded object because of the mechanism of lazy loading. Therefore, an exception would thrown.

       One of the good way to handle this problem is using Exposed Domain Model Pattern instead of POJO Facade Pattern. We also call Exposed Domain Model pattern as Open Session in View Pattern. It means the presenter layer can access the business logic layer directly instead of through a facade class.  It is obvious that the advantages of POJO Facade pattern are the disadvantages of Exposed Domain Model. However, If you want to avert the complexity of writting the detached objects, in fact, which are also weak,  Exposed Domain Model pattern is still a good choice.

       In POJO Facade, the facade class need to take care of managing transaction and database connection. In Exposed Domain Model, we have to distribute the two functions to the other parts of the system. Because we have to keep the Hibernate session availabe until the presenter layer finishes rendering the page, the servlet filter is a good place to open and close a session. Spring framework provides such a filter named “OpenSessionInViewFilter” to help us realize this.  Furthermore, we can also start and submit a transaction in the servlet filter. However, it is too complicate to write code to restart a transaction in the servlet filter. Usually, we let the classes in the business layer (for example, the service classes in the domain model) to deal with the transaction.

The following is an example of web.xml file to show how to config spring framework in web.xml:

<web-app>
         /*the listener watches over the creation of ServletContext which store the spring applicationContext*/
        <listener>
             <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
        </listener>
 
        <context-param>/*list the spring configuration files*/
             <param-name>contextConfigLocation</param-name>
             <param-value>/WEB-INF/applicationContext.xml</param-value>
        </context-param>

        <filter>
               <filter-name>OpenSessionInViewFilter</filter-name>
               <filter-class>org.springframework.orm.hibernate.support.OpenSessionInViewFilter</filter-class>
               <init-param>
                        <param-name>sessionFactoryBeanName</param-name>
                        <param-value>sessionFactory</param-value>
              <init-param>
       </filter>

       <filter-mapping>
               <filter-name>OpenSessionInViewFilter</filter-name>
               <url-pattern>/*</url-pattern>
       </filter-mapping>

       ……..
</web-app>

POJO Facade

      The day before yesterday, I made a brief introduction to the Facade pattern. Today, let’s make a little bit advance. Because I am studying lightweight frameworks now, I am pretty willing to share my own knowledge about POJO facade pattern with you!

      From the name of POJO facade, it is easy to tell that it is based on the facade pattern. The main responsibility of POJO facade is to manage the transaction and database connection. In fact, when we refer to POJO facade, we always like to compare it with Session facade. They have two big differences. The first one is POJO facade donesn’t need the services provided by the EJB Server. Because POJO facade pattern is specific for lightweight framework, such as Spring and Acegi Security, which will provide services to it instead of EJB Server. The second difference is that POJO facade choose to return the domain object to the present layer instead of DTO(Data Transfer object). As we all know, DTO just holds data and not has behaviros. The biggest disadvantage of DTO is that we always need to write a lot repeated and redundant codes to create it.

      As mentioned above, POJO facade returns domain objects to the present layer instead of DTO. However, this way has one drawback that the present layer may call the mehtods of the domain objects directly instead of through POJO facade, so that these calls will not be executed in transaction. In order to solve this problem, we can combine POJO facade with Adapter pattern. Firstly, we define an interface, which contains all the methods the present layer need access. Then, we should create an adapter which implements this interface. And this adapter will transfer all the requests from the client to the domain objects.

     When we use POJO facade, another problem we need to concern is that how the POJO facade returns the domain objects to the present layer(we call it detach). Because of the problem of open session in view. We have to make sure the domain objects returned by POJO facade are the ones needed by the present layer, and the present layer will not access the other domain objects which have not beed loaded from the database.