The power of JQuery and JQGrid

9 05 2010

Off late, I have been working (yes, hands on) on some web applications, after a long gap!! Historically, we were stuck using Struts and Displaytag for our jsp based data grids, to support CRUD operations. As we started revamping our web applications piece by piece, we looked at several options, including JSF. With the time constraints at hand, our choices were pretty much limited and we confined ourselves to look at Ajax based frameworks. We fumbled upon JQuery and its rich set of plugins. Since then, we never looked back. We did try ExtJS, Prototype and other AJAX based frameworks, but nothing matched JQuery.

To make it short, we liked the following:

  1. The Selector API of the core JQuery framework.
  2. The UI components (Modal dialog, DatePicker, Accordion, Tabs etc).
  3. A rich set of plugins, which made our life so easy (JQGrid, JQuery validation etc).
  4. Theme based look and feel (switching themes is only one line of code).

Our turn around time was pretty quick and users were really happy with the UI look and feel and response times.

For people who are not aware of JQGrid, please visit their demo site. JQGrid was the datagrid component which we used to replace Displaytag. We integrated this with Struts and used our Spring/Hibernate based DAO layer to support the CRUD operations, pagination and Data export features. We resorted to JasperReports/iText for PDF based canned reports.

Even though I have immense belief in standardised API’s like JSF, the steep learning curve, the poor performance and availability of developers who “really” understand, have put us off!!





Transactional Memory, a distant dream?

28 03 2009

Have you ever felt the necessity for writing code which looks something like this?

atomic {
obj = msgNotProcessedMap.get(key);
obj.setProcessedTimestamp(timestamp);
msgProcessedMap.put(key,obj);
msgNotProcessedMap.remove(obj);
}

Well, I have been following the evolution of both software transactional memory as well as hardware support for it. Back in 2006, when I first started my in-depth look at this new emerging area, I felt that there was a lot of promise and expected it to go mainstream pretty quick, but here we are, in 2009 now, and I have become a bit skeptical.

There is still a lot of ongoing research in this area and there are a few STM implementations available out there, but they are not really mainstream. As skeptical as I am, I still see some hope for it to be part of Java 8.0 or C# 4.0, yes, nothing short of native language support.

Sun Microsystems has come up with their Hybrid Transactional Memory (HyTM), which uses STM as much as possible and exploits the underlying hardware when it comes to optimistic concurrency control. Sun has confirmed it’s on track to ship its “Supernova” servers based on its “Rock” UltraSparc-RK processors before the end of 2009, so let us wait and see.

Without native language support, the effort that a programmer has to incur would be significant and in a way more error prone than what they are accustomed to currently (synchronized constructs and locks and mutexes).

The current benchmarks floating around for STM , doesn’t look that promising, even when running on multi- core processors, which are very prevalent nowadays. Cliff of Azul systems makes a point in his blog , that under heavy load, the performance is unpredictable. Another article on ACMQueue gives us a “not very optimistic” viewpoint.

But I do believe that Sun’s hybrid transactional memory approach will eliminate many of these known limitations of STM alone (inability to distinguish between transactional execution vs non-transactional execution, user code being able to see in-consistent state inside an in-complete transaction etc).

The only silver lining is this latest paper, published by Sun at the Fourteenth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS ’09). It shows us that the folks at Sun have made great strides and the benchmark results sound very promising and makes us really believe that we are closer to mainstream adoption.

Time will tell.





Another article on Distributed transactions

3 02 2009

I found this new article at at JavaWorld, written by Dr. David Syer, who works for SpringSource . The article elaborates on using different transactional strategies/patterns and provides some advice on which strategy/pattern to use in a particular scenario.

The emphasis was primarily on using distributed transactions without XA (read overhead), of course, with some trade-offs. I found it very informative.





Is JBOSS losing the sheen?

3 06 2008

We use JBoss a lot in our organization and as far as my responsibilities go, I am involved, in someway or the other, in design and architectural/infrastructural issues, which also include JBOSS based applications.

I noticed that the first Beta of JBoss 5.0 AS was released way back in 2006-11-17. And since then, there were 3 more Beta versions, the last one was released on 2008-02-10. It is almost 2 years and we don’t have a GA release available yet.

Could it be the RedHat acquisition and the related transition, the reason for this? Or is it the attrition rate at RedHat?

I hope the GA release, whenever it releases, will be worth the wait. They(Redhat) should also take note of the competition coming from other open source application servers, especially GlassFish. I have never used GlassFish, but based on what I heard from others, the list of features it provides, and the pace at which they are releasing, they definitely seem to have more momentum than JBoss.

Though the adoption of JEE5 based application servers has been very slow, it has been steady. The only commercial application server which is JEE5 compliant is Weblogic 10. Websphere is way behind, but I could be wrong. Websphere community edition (Geronimo?) has JEE5 compliant features (or shall we say compatible?) but I don’t think it has that much of a momentum, despite being open source.

I hope Redhat is listening.





Understanding JMS messaging

25 07 2007

To my surprise, I am learning that there are very few java developers/programmers who understand the JMS specificaiton. There was this application which was consuming messages using a synchronous recieve call (with an AUTO_ACK mode), the programmer was expecting that the message be re-delivered if his application fails after the receive() and eventually blames the JMS server. The programmers fail to understand the difference between synchronous receive() and asynchornous receive (via MessageListener).

In another instance, I was informed that the JMS server was not JMS compliant just because it wasn’t closing the producer explicitly. The architects of that application were thinking that java’s garbage collection would take care of cleaning up the producers, if not explicitly closed. The JMS 1.1 spec is pretty clear on this and I find it very difficult to understand why and how one can interpret this differently.

The same is the case when a standalone application uses Spring MDP’s for consuming messages. Spring has this DefaultMessageListenerContainer which does a synchronous receive(). If one were to set the AUTO_ACK acknowledge mode, and the application fails after the receive() call, the message is lost. This is not clear to many of the users.

Maybe it is time for someone to come up with a list of messaging anti-patterns and educate the JMS/messaging community in general.





Messaging at wire speed?

21 07 2007

My ex-boss mentioned about Tervela a while ago and I finally got a chance to learn more about it.

Coming from the Java world and having been exposed to JMS implementations like Tibco EMS, Websphere MQ and ActiveMQ; this came as a surprise to me and I would like to share this with everyone.

Tervela’s product is a messaging appliance which runs on the metal.

Its key features are as follows:

  • Message transformation and routing at the network level (layers 1-3). This will pretty much eliminate the network interrupts, which would otherwise overload the processor with interrupts for every packet that was received (thus increasing the latency). Besides this, the requirement for queuing of messages at the entire network stack, which is pretty common with software based messaging systems running at the application level messaging, is eliminated too.
  • Native instruction sets optimized for specific tasks and its pipelined architecture (no scheduling and interrupts so reduced latency).
  • No broadcast storms (a result of crybaby phenomenon). A typical scenario will be when a consumer is unable to catch up with the message load and thus drops some packets and requests for re-transmission. This is very common in multicast based communications and the re-transmitted message is eventually sent to all the consumers, instead of sending it to the consumer who requested it.
  • Custom routing algorithms eliminating filtering of the messages at the client level.

As you can see, the appliance mainly targets the financial verticals and will be a good fit for handling market data feeds at wire speeds (pub-sub domains). If you are looking for JMS semantics, look elsewhere 😉





My article – XA transactions using Spring framework.

24 05 2007

I recently authored my second article at JavaWorld. It mainly demonstrates how one can utilize distributed transactions (JTA/XA) in standalone Java applications. The article focuses on how one can integrate different standalone JTA implementations (JBossTS, Atomikos and Bitronix) using the widely popular Spring framework. Please let me know your comments, if you get a chance to read.