Enterprise Live

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...