Enterprise Live

The biggest challenge around building an efficient data model for Cassandra is data redundancy. Though the basic rules for data modelling with Cassandra, mention the usual RDBMS modelling goals, as non goals for Cassandra (Refer:  Basic rules for C* data modelling ), it builds upon assumptions that clusters are built on commodity hardware, storage is cheap, and as data needs increase more nodes can be added to the cluster incurring very low cost. But in real life we are faced with technical as well as non technical problems. a. Keeping multiple column families in sync can be a major overhead, if the same data is spread across them. What if writes to some CF succeed and some fail? How long and how much will we retry? b. Horizontal scalability may be a truth, but think of a mundane question of where to keep all those heat producing, energy guzzling machines? So how do we model the database that does not allow joins without redundancy? The simple answer is, we do not. Wh...

Let's face it, change is the way of life. Inevitably, change is the way of software too. In case of enterprise applications change is continuous. This comes in the form of new business requirements involving complex logic and changes to the interfacing systems. Logic can change on its own and usually does not cause changes to interfacing systems. But the other way round is a completely different story. It is an extremely bad practice to let interfacing systems' scheme (classes and relationships) to propagate through your application. No one does that, no one should. We depend on the use of Adapters, DAO and Value Objects that carry data through our applications and let our logic run on those. Yet, one complexity lingers, how to safely and easily move from one interface to an alternate one. Say today our application uses a traditional relational database like Oracle and we want to replace it with a NoSQL database like MongoDB or Riak or Cassandra? Changes to value ob...

To start with, let's hear it from the horse's mouth: "What Is Google App Engine? Google App Engine is a Platform as a Service (PaaS) offering that lets you build and run applications on Google’s infrastructure. " But what does it bring to the table, when it comes to deciding how and where to host you r application when you "start up"? Besides all else, first consideration is cost. As a startup, let's face it, you'll be broke. Pricing for app engine is based on traffic and usage, and while we would want a lot of traffic it won't happen at the onset. Until your product really kicks off, you get it all for free. The application being built as modules, also allows developers to apply principles guiding enterprise application build. And viola, you have a highly scalable enterprise application built on a robust and high availability platform. A product at its onset will also be dynamic (hope it is stable before you install, unstable pr...

In the world of container managed transactions, Java provides a highly misused feature called XA transactions. In simplest terms XA transaction is a global transaction that spans multiple resources. The implementation provides a transaction manager that allows applications to perform interactions with multiple resources as a single unit of work. A lot of applications end up using XA adapters when they have multiple databases to deal with or just because of future possibility of using multiple database interactions. CMT hides transaction management and developers are not bothered with the nuances of the same, until something goes wrong. And with XA, it can go wrong a lot. I planned to explain why, but then I found this very relevant post, so I'll leave it at that. Distributed transactions are evil Instead, let's focus on the solution since interactions with multiple resources is a fact of life. It is neither a good idea, nor a practical one to keep all the data that an a...

A lot has been written about transactions, a lot I read. Yet here is some more that I am planning to write in context to what we face in real life situations while developing enterprise applications. A few of the forthcoming posts will be dedicated to transactions before I start moving into other pain areas that we developers face in actual development situations. To start with, let's consider what Transaction is. Out of the book, it is defined as a unit of work that either completes or fails. Try digging deeper and it starts getting all confusing with isolation levels, ACID concepts and lot more. But here we shall not rewrite what is already present in a lot of documentation. What we shall deal with today, is the intent of transactions. Why do we have to consider transactions in the first place? Understanding that is imperative for developers to correctly identify "transaction boundaries" when it comes to real implementation. Any piece of code executes as an inter...