Database Connection Pooling

Database connection pool is a collection/group of identical JDBC connections to a database. These connections are created when the connection pool is build or as and when a connection is required.

The applications usually interact with some form of database and getting a connection from the application to fetch/update the data in the database, require some time which is unacceptable if we create a new connection each time we need to interact with the database.

The idea is that you create some connections and put in some form of pool from where the application can pick a connection when required. Since, the time taken to make a database call is usually quite small, the application can use the connection and return it back to the pool. This makes sure that at any given point of time, you would not need more than n number of connections.

Advantages of using connection pool:
1. As mentioned above, it is more efficient to obtain a connection from the pool rather than creating a new one whenever the application needs to talk to the database.

2. Connection pool provides a form of abstraction such that the application does not need to know the details of how to create a connection and details such as username/password etc.

3. The above mentioned abstraction also provides the flexibility to change the underlying database without any changes in the application code.

4. Using the connection pool ensures that you do not have a lot of connections open at the same time. This is possible because the connections can be reused by the application components.

Core J2EE patterns: Business Delegate

Context: The client does remote method invocation and is exposed to the complexity of the underlying business service implementation

Problem

1. Different clients need to access business services.
2. The client is exposed to the implementation of the business service.
3. If the service implementation is modified, the client is also affected.
4. Unncessary network communcation (too many invocation perhaps)

Lets take an example where we try to take care of the above mentioned problems.

The client lets say a swing client needs to invoke a remote method.
We can follow the following strategy.

1.Swing class lets say AccountUpdateServerCommand, needs to invoke a AccountUpdateSLSBean.update(some information)

We will write the following classes:
a. AccountUpdateBD
b. JNDIHelper
c. BusinessServiceFactory

2. AccountUpdateBD is the business delegate for the AccountUpdateSLSBean.

3. The AccountUpdateBD and the AccountUpdateSLSBean lets say implement IAccountUpdate interface.

4. Now, AccountUpdateServerCommand invokes BusinessServiceFactory to get reference to the AccountUpdate.

5. BusinessServiceFactory will instantiate the AccountUpdateBD class and return the interface reference.

6. AccountUpdateServerCommand gets back is the IAccountUpdate reference to the AccountUpdateBD instead of the AccountUpdateSLSBean.

7. AccountUpdateServerCommand invokes IAccountUpdate.update() method.

8. AccountUpdateBD.update()will use JNDIHelper to get the remote reference to the AccountUpdateSLSBean. JNDIHelper will make a lookup and return the reference.

9. AccountUpdateBD.update()will then invoke the update method on that reference and return the value to the AccountUpdateServerCommand class.

uses
Client ----------> BusinessDelegate-------------> Business Service
^
lookup/create
Look up service -------------------


Benefits

1. Reduces coupling between the client and the business service

any changes in the service implementation donot affect the client. No changes required in the client.

2. Translates business service exceptions.

Business delegate can handle system exceptions and throw application exceptions to the client.

3. Failure recovery

Business Delegate can have automated failure recovery.

4. Performance

Business Delegate improves performance. It can cache the service references.

5. Hides remeoteness

The client programmer does not to know the details of how to connect to the business service. It provides location transparency and hides the dirty details.

Pessimistic and optimistic locking

Pessimistic and optimistic locking

There are two different ways transactional locking is done.
Pessimistic and optimistic locking and that is how transactional isolation is achieved.

When we do pessimistic locking, we lock the resource when it is accessed the very first time and the lock is not released till the time, transaction is finished i.e, either committed or rolled back. The disadvantages of this apporach will be that the resource will be locked and no other process can access this resource till the lock is released. This can result in lock contention and the other processing trying to access the lock will be either delayed or their transaction will be rolled back.

WIth the optimistic locking, the resouece is not locked the way it is done in the case of pessimistic locking. The time the resource is first accessed, the state of the resource is saved. And when it is the time for the resource to be updated, the current state and the saved state is matched. Is their is any difference, the transaction is rolled back. This way the other transactions are not rolled.

This is the theory, but I am not sure how it works in reality. Sounds to me to be a complex way to achieve transaction isloation and what if this resource in question, is accessed frequently. Will this not result in performance bottleneck?

Spring framework

These days I am reading the book. Spring: A Developer's notebook. A real fundu book. Just finished the basic understanding part and now reading how to implement MVC based on the spring framework.

What surprises me is the ease with which you can write code with Spring. So simple, yet beautiful and powerful.

Spring and EJB

Why Spring makes sense?

1. Spring keeps the framework out of the code. i.e, no framework-specific requirements on objects.

2. Spring is simpler than EJB mostly because they take a more POJO-based approach,

3. Code is not heavily dependent on the container so unit testing is easy.
You can even run some integration tests using a Spring container but not a heavier J2EE app server–unlike any app server, a Spring container takes very little time to start up.

JProxy

JProxy is an J2EE HTTP tunnel with SSL and JAAS support for EJB, RMI, JNDI, JMS and CORBA. It was designed with the thought of creating a unified object model that lets you design your solution Internet without worrying about HTTP, Firewall drawbacks, implementation differences between different Application Servers, and integration between J2EE and CORBA standards.

JProxy enables CORBA, JMS and RMI services on the Internet.
Make remote calls to interfaces that weren’t originally designed as remote ones. JProxy will remote those interface for you at runtime.
JProxy client runtime is only 90K - no more wait for a client to get started on a customer machine.
JProxy supports asynchronous communication over Firewalls without polling.
JProxy supports built-in fail-over mechanisms for your clients with broadly customizable policies.
JProxy compresses and optimizes remote calls. Clients downloaded on your customer’s computers won’t trigger any Security Warnings because JProxy doesn’t violate any default security rules.

Reference: http://javaboutique.internet.com/JProxy/
Author: Marat Bedretdinov

Easie and Myeclipse

Note: If you are not able to see the pictures in this post clearly, I would suggest saving these pictures locally and then using any picture viewer tool to enlarge it.

One of the projects I work on uses Easie welbogic plug-in. The development environment is already established and there is nothing much left there to experiment with. To understand it better, I thought about installing this plug-in and get my hands dirty on it.

I checked out the easie web site. They have discontinued with easie and have instead come up with something called myeclipse. It is essentially a J2EE IDE.

To try it out and establish a complete development environment for Weblogic server, I downloaded Myeclipse Enterprise Workbench v3.8.4. It requires you to have JDK and Eclipse 3.0.1 installed.

I installed Eclipse 3.0.1 first. Not much of a problem. Thereafter, I installed myeclipse. During its installation it will ask for the Eclipse installation folder. Rest everything is very easy. Just follow the steps.

Once, you have Myeclipse installed, start the eclipse IDE. You will find a new perspective "MyEclipse" and a new menu option "Myeclipse". If you can see the perspective and the menu option, it means that the installation was sucessful.

The next question was how to install and run Weblogic server. Searched on google. No luck. After wasting some time, I searched on yahoo.com, and got a wonderful link http://www.myeclipseide.com/ContentExpress-display-ceid-40.html

This page explains how to setup various application servers in myeclipse and run them.

Steps to configure and start Weblogic server.

1. Download Weblogic platform from BEA site. Install it.

2. Run COnfiguration wizard. Create a new server and domain.

3. Start eclipse. Go to Window->Preferences->Myeclipse->Weblogic8. You will find a number of configurable items here.

4. Except JAAS login configuration file, I specified all other options as you can see in the screen shot below.



Once you are done with it, Go to JDK option in the Weblogic8. In the WLS JDK name prompt, click on Add. You will get a screen like below.



Mention some name. Can be anything. I gave the name WLSJDK. Specify the JRE Home directory(the one that comes with WLS) I gave C:\bea\jdk142_05.

Caution: I tried first to give the path of JRE I had installed at some other location. But for some funny reason, cause of this the WLS server did not run. I wasted another half an hour here. So take care that you mention the JRE location in
your Weblogic installation directory and not some other JRE or JDK installation.

5. Once you are done with all this. Press ok. Now we are ready for starting our Weblogic server.

6. Click on the icon as shown in the picture below.



7. You should now be able to see an option to start weblogic 8. Click on start option.



8. If everything goes fine, within next few sec, you should be able to see the message of weblogic server listening at port 7001 in the console.



Tomorrow, I will write a small application and run in myeclipse.

Happy learning
Deepak

Introduction on JCoverage

Hi!

Today, I attended a small session on JCoverage. Not much in detail. But enuf to move forward. JCoverage lets you find out how much of your code is covered with your JUnit test test cases.

In the example we worked on, we wrote some code and Junit test cases.
Then we modified our ant build file. We defined another target 'instrument' like below:

<target unless="skip.build.instrument" depends="init" name="instrument">
<taskdef resource="tasks.properties" classpath="jcoverage/jcoverage.jar">
<instrument todir="${instrumented.dir}"">
<fileset dir="${classes.dir}"">
<include name="**/*.class"">
<exclude name="**/*Test.class"">
</fileset">
</instrument">
</target">

In this target, we take all our source class files. JCoverage takes these class files and then creates new class files, which are almost identical to the original class files, with the exception that after every line of code, it puts some line of code, which will help it to find out later whether the line of code was unit tested or not.

After this we modify our 'junit' target like below

-<target unless="skip.build.junit" depends="init" name="junit">
-<junit dir="${basedir}" fork="yes" errorproperty="test.failed"
failureproperty="test.failed">
<classpath location="${junit.other.classpath}">
<classpath location="jcoverage/jcoverage.jar">
-<classpath location="${instrumented.dir}">
<classpath location="${classes.dir}">
<formatter type="xml">
<test name="${testcase}" todir="${result.dir}/reports/junit" if="testcase">
-<batchtest unless="testcase" todir="${result.dir}/reports/junit">
-<fileset dir="${src.dir}">
<include name="**/*Test.java">
</fileset>
</batchtest>
</junit>
<report destdir="${result.dir}/reports/coverage" srcdir="${src.dir}">
<report destdir="${result.dir}/reports/coverage" srcdir="${src.dir}" format="xml">
</target>

As you can see we have modified our class path here. So what happens is that when you execute the test cases, it picks the instrumented class files and not the original class files.

We then defined another task "jcoveragereport' like below

-<target unless="skip.build.jcoveragereport" depends="init" name="jcoveragereport">
<taskdef resource="tasks.properties" classpath="jcoverage/jcoverage.jar">
<report destdir="${result.dir}/reports/coverage" srcdir="${src.dir}">
<report destdir="${result.dir}/reports/coverage" srcdir="${src.dir}" format="xml">
</target>

This will generate some reports. In these reports, it tells us how many lines of code were covered in the test execution. How much percentage of branches were covered in test execution and so on. It also shows the source file in this report, with all the lines which were not covered in the test cases marked in yellow color.

For example: if there is some code in our source file like this

if(...)

......

else
......


Now, if in our test cases, with some input values, we executed the if part of the code block, and didnt check the else part, in the report it will mark the else part in yellow color, indicating that this portion of code was not unit tested.

You can more details on Jcoverage from http://www.jcoverage.com/

Happy learning
Deepak