Limit rows fetched in a JPA relation

These days I’m playing with Java EE stuff to build a new REST based application. I’m using GlassFish server, Jersey (for JAX-RS) and JPA (via EclipseLink) for my application.

While learning stuff, I got stuck in a problem – suppose you have a customer entity. Each customer can have multiple orders. So it’s a One-Many relation:

Each customer can have many orders. It may be very well over hundred or thousand. But what do you do when you want to fetch only last 5 orders? The obvious way would be to do by fetching using EntityManager. But wait, this is a relation. How to limit in a relation?

Suppose the REST service is like this:

When the Customer object gets marshaled by  JAXB, it will fetch ALL the orders that are related to the customer and send it to the client.
In the entity, we specified that the relation fetching should be lazy that is don’t fetch until the property is accessed. So, instead of having JPA load all the orders when  JAXB accesses the property, we fetch it manually in the REST service and set the property of the customer object, something like this.

Customer.findOrders can be a NamedQuery:

It’s quite trivial, but it took me three whole days to research for this solution.

A failed experiment with GlusterFS

GlusterFS is a clustered file system that can be used when you want to share the content across different machines which can be accomplished by NFS as well. But the difference is, NFS failover is hard.

In GlusterFS, you can add two servers known as bricks in Gluster’s terminology on which your volume can be created as a replica. All data is replicated to both the servers by Gluster. GlusterFS has support for advertising the volumes as NFS shares as well, but I didn’t use it because of the basic reason – failover.

Continue reading

Views on recently launched Chromebook

Recently Acer launched a new Chromebook with fourth generation i3 processor. As per specifications it will come with 32 GB SSD and will have USB 3.0 port as well. All at a rate of 380$ which is around 23k INR as of writing this article.

Personally I’m not interested in tying myself to a closed sourced OS. I’ve been using Linux since 2007 and can’t move away from various nifty features I get due to either working on the command line or due to desktop environments like KDE and GNOME.

There are a few points which makes that Chromebook ideal for me -

  • It is affordable, in fact cheaper than most smartphones launching these days.
  • It can run Linux. This one’s rather important.
  • It has USB 3.0, a missing feature in most budget laptops which come with Windows or FreeDOS installed, so I can connect an external HDD for my data.
  • It has 32 GB internal storage. Currently on my home computer, I have a 128 GB Samsung SSD for OS. My Gentoo installation with GNOME requires about 10 GB. That leaves me with 12 GB data storage directly on the SSD.

I’ll see when this gets launched in India, and will try a demo at some showroom if possible. It’s highly likely that this is my first laptop.

Load balancing with Linux Virtual Server via Tunnelling

A post after almost a year. But finally I have something new to post.

Linux Virtual Server is commonly employed for load balancing between multiple servers. The load balancer and real servers share a common IP address called virtual IP.

There are three methods for using LVS – Direct Routing, NAT and Tunnelling. The first two methods require direct link between your machines and you should be able to control the routers. There’s no such restriction in the tunnelling method – the servers can be even spread over WAN many kilometres apart.

Continue reading

%d bloggers like this: