Shashi Velur’s blog

I think it is very hard to build any enterprise application without using at least a little bit of straight Jdbc. Even if an application uses Hibernate heavily, there will be situations where using straight Jdbc makes most sense.

We use HibernateDaoSupport (using GenericDAO pattern) and JdbcDaoSupport Spring classes as the base classes for the HibernateDAOs and JdbcDAOs respectively. 

Here are some of the things to be aware of when we mix these 2 techniques for the CRUD operations within the same transaction:

• The HibernateDaoSupport beans and the JdbcSupportBeans should be wired with the same DataSource instance.
• Use HibernateTransactionManager, which auto-detects the DataSource used by Hibernate and transparently uses Hibernate transactions as JDBC transactions for that DataSource (using ThreadLocal connections).
• When using CMT or using declarative transactions using Spring AOP (Spring Transaction interceptors), the connections must be explicitly closed by the Jdbc DAOs. Otherwise, this leads to connection leaks. See Hibernate JavaDocs for Session.connection() method for more info. My favorite way to avoid this problem is to use Spring JdbcTemplate inside the Jdbc DAOs.
• Explicit flush on the Hibernate session may be required wherever Jdbc calls need to read the updates made through the hibernate objects within the same transaction.
• Explicit invalidation or refresh of the Hibernate Session is needed whenever updates are made through Jdbc.
• Hibernate by default uses Optimistic locking. So, the retry logic needs to be implemented in appropriate places.

As you can see it can get very tricky to synchronize straight Jdbc and Hibernate updates. So, I would try to use straight Jdbc only for bulk reads and reads that require complex joins, if possible.

Technorati Tags: Hibernate, Hibernate Transactions, Straight Jdbc

One very important thing that I have learnt from my consulting experience (dealing directly with Clients for building solutions) and in my experience of building exterprise products is:

When you are given a set of requirements, always understand the requirements in terms of what problem of the Customer (an actual client or the product owner) is this requirement trying to solve, instead of just treating the requirement as a feature or an enhancement request.

This may sound very simple, but it has far reaching implications in building great products/solutions. With a good understanding of the inner workings of the product or the architecture or technology or just out-of-the-box thinking, sometimes certain extremely simple alternative solutions might just do the trick with very little or almost no work/re-rework required..!

This was reinforced by one of the examples given by Mary Poppendieck in the Lean Management principles presentation I attended recently:

In the Military/Army, the communication given to the soldiers consists of just 2 things:

• End State
• Command Intent

So, the “Stories” or “Requirements” should specify the “what” and not the “how”.

Technorati Tags: Agile, Lean principles, Requirements, Story

I just found out that my Akismet WordPress plugin has been eliminating some valid comments on my blog by “hard-delete” instead of a “soft-delete”.

I cannot believe this. I just lost over 30 comments some of which may have been some good comments.

So, I now cannot get to those supposedly blocked “spam” comments - they do not exist in the DB tables. I just found that out today. So, had to swiftly deactivate/uninstall it and install another one, ”SpamViewer”.

Hope this one works better.

Technorati Tags: Akismet, SpamViewer

I am in the process of rearchitecting a fairly large legacy web application. Almost all of the classes in the old code base are public classes with the key classes containing mostly public (and sometimes static) methods. I am tasked to modularize this application for various obvious reasons in an evolutionary and progressive manner.

Java package names are used for various purposes such as:

• Namespaces for tiers (web-tier, middle-tier, EIS-tier, etc.)
• Namespaces for layers (service layer, DAO layer, etc.)
• Namespaces for the purpose of the classes (Utility classes, implementation classes, etc.)
• Namespaces based on module structure, deployment architecture, etc.

So, it is not always possible to put the implementation classes and the classes that need to access the implementation classes in the same package for any combination of the above reasons or use inheritance between them. So, the standard Java package-private and protected access specifiers might come up short.

So, one of the consequences of these restrictions in Java is to make the class public, eventhough you may not want this class accessible to every other class in that module/bundle or classpath by default (depending on whether you are talking about OSGi or non-OSGi based applications).

Sometimes, I miss the C++ “friend” Class (not the function) access specifier. However, I think the “friend” class in Java should not have access to all of the private members, instead it should have access to the “friend” or “protected” members of the other class. But, perhaps the designers of the Java language may have decided against this due to fear that the not-so-OO-developers might violate encapsulation by misusing this feature.

I have seen or heard of various approaches to solve this problem:

• Use Delegation and/or Composition
• Use “internal” package names
• JavaDoc them as “for internal use only” (org.springframework.orm.hibernate3.SessionHolder in Spring API)
• Use classloading trickery to simulate “friend” access specifier. This may not work in web applications or OSGi (due to the “modularity” or various classloading architectures))

My preferred way to do this (if I absolutely cannot put them all in the same package and make them package-private) is to use delegation or composition or a factory class (depending upon the type of situation that causes this problem).

What do you think? Are there better ways to do this?

Don’t we need a modified form of “friend” access specifier in Java?

Technorati Tags: encapsulation, friend access specifier, Java friend class

Here are the things every Java developer working on OSGi-based middleware must know, IMO:

Essentials:

• Design-by-Contract & SOA
• Component/Package Versioning
• OSGi Bundle Lifecycle
• Bundle Manifest directives
• Core OSGi services
• Spring DM (especially for simplification of the usage of OSGi services and writing in-container tests)
• BND tool (I cannot think of a better way to create the OSGi manifest files than this)
• Basics of classloading in OSGi

Advanced Topics:

• HTTP Server options in OSGi (OSGi HTTP Service, HTTP Servlet Bridge, etc.)
• OSGi “uses” directive and the “type leakage” problem
• OSGi Services vs. Extensions/Extension points
• Service Trackers
• Concurrency gotchas in OSGi
• The Whiteboard pattern
• The “Extender bundle pattern”
• OSGi Declarative Services and Configuration Admin Service

Technorati Tags: OSGi, OSGi essentials, Whiteboard pattern