Archive for the ‘Programming Tips’ Category

Introduction to JPA

Well its that time of my career where you need to sharpen yourself again to find stumble on the right career path for you and for me it means finding the right project. Originally being a Linux, C/C++ guy, I couldn’t simply ignore the Java buzz and the importance different pieces of Java plays in the architecture world.

Talking about architecture, database enabled Java enterprise applications are of prime importance as they form the basic of any application deployed in the enterprise world.Taking it a bit further,knowledge of persistence APIs are a must have skills in your resume if you want to survive the competition. So this multi-part blog is an effort to help programmers like me to deep dive into the basics of persistence with Java.

2006 saw the final release of EJB 3.0 which was based on JSR-220 (Java Specification Request). This release gave the programmers the ability to store and retrieve application data to and from the database respectively.  This set of APIs is known as the Java Persistence API  or JPA. JPA incorporates many of the concepts and standards from leading persistence frameworks like Toplink (from Oracle) and Hibernate (from JBoss). One of the great benefits of JPA is that it is an independent API and can nicely integrate with J2EE as well as J2SE applications.

By plain definition in Java terms, Java Persistence API (JPA) provides POJO (Plain Old Java Object) standard and object relational mapping (OR mapping) for data persistence among applications.

So what is POJO?

Plain Old Java Object is a term used to refer Java objects that do not extend or implement some specialized classes. The following classes are not POJO classes because the first one extends a specialized class and the second one implements a specialized class.

    class MyServlet extends HttpServlet {}
    class MyRemote implements SessionBean {}

What is Object-Relation Mapping?

OR Mapping – Object-Relation mapping is the process of the transformation of the data between the class objects and databases. Applications can depend on an OR-M like tool that greatly simplifies this work instead of manually coding the transformation process.

Entities

Persistent Data normally refers to permanent data in an application. The state of these data is made permanent by storing them in a persistent medium like database, files or a disk tape. In JPA terms, these persistent data are referred as entities. An entity refers to a logical collection of data that can be stored or retrieved as a whole. For example, in a banking application, Customer and BankAccount can be treated as entities. Customer name, customer address etc can be logically grouped together for representing a Customer entity. Similarly account number, total balance etc may be logically grouped under BankAccount entity.

Since entities form the heart of the JPA, they have some unique properties like

  1. Persistability:- deals with the storing and retrieving of entity from and to a persistent medium like database.
  2.  Identity:- is usually used to identity one unique entity among multiple entities (or multiple entity instances) in a database.
  3. Transactionability:- CRUD operations (Create, Update and Delete) for entity objects will occur within a transactional context and it is one of the major characteristic for an entity object as the real state of an entity depends whether a transaction completes (commits/fails) or not.

Next article in series:- Creating entity classes.

Advertisements

Well back to blogging after a real long time. Last few months has been challenging for me and left me with no time to blog especially after 18 to 20 hours of work schedule with little or almost no sleep. Well now that the pressure is a bit off, I am back to my code cafe with lots of learning from my last 4 months experience, which I will share slowly and steadily so that I don’t miss out on anything.

In this series I would start off with the most challenging problem I faced and it was related to a character set issue. Today there are lots of talk about Unicode and multi-byte character sets. No doubt they are wonderful and help in broadening the audience scope, however sometimes while working in heterogeneous environment it becomes more easier to stick to single byte character sets. In my case the backend was mainframe, middleware was linux and the client was either unix, windows or AS400.

Problems usually arise when dealing with binary data. The binary data contains characters which are higher in value and represent a multi byte character in Linux or any other Unicode system. The problem that I faced was my middleware server and client was completely dealing with bytes and not characters or strings. So when I received a multi-byte character from backend and was transmitted to the client it was transmitted as 2 bytes which I didn’t want. On the client end I was dealing with a fixed length response file. Any increase in the bytes than expected would give me surprising results and this is what happened. The multi-byte characters behaved as two different bytes when looked from the byte point of view. The response file that got generated shifted data to the right and I encountered data loss on Windows response file and more dangerous results in AS400 response file.

The fix:

The real fix was to prevent Linux from converting a high value character into a multi-byte system and rather treat it as a low value single byte character system. If you are working on a Linux system setting your environment variable LANG to en_US instead of the default en_US.UTF-8 helps fix the problem.

just try:

export LANG=en_US (on Red Hat or Fedora Systems)

However if for some reason you can-not set the environment variable then you will have to do a bit of math here to get your multi-byte character in to a single byte character. If you are dealing with strings, break the string in to individual character (each character can be stored in multiple bytes), then treat them as integers. Any high value character will have an integer value less than 0. For such characters add 256 to the integer value and use the new character. The final character array you would recieve will be in a single byte system.

The only way to verify the integrity of your string is use the hex value of it to verify. Before you convert your string into a single byte character encoding, grab hex value of the string. Then after conversion, grab the hex value again. They both should match.

I hope this information helps others who are working in a hetergenous environment and prevents them from putting the amount of time and energy that I had put to resolve my problem.

Rich Skrenta writes about a presentation given by Steve Souders of Yahoo :

Steve Souders of Yahoo’s “Exceptional Performance Team” gave an insanely great presentation at Web 2.0 about optimizing website performance by focusing on front end issues.

Rich has summarized the whole presentation (which he says is worth a book) into 14 rules for faster front end performance:

# Make fewer HTTP requests
# Use a CDN
# Add an Expires header
# Gzip components
# Put CSS at the top
# Move JS to the bottom
# Avoid CSS expressions
# Make JS and CSS external
# Reduce DNS lookups
# Minify JS
# Avoid redirects
# Remove duplicate scripts
# Turn off ETags
# Make AJAX cacheable and small

Download the complete presentation here