cwash into software

In Part 1, we covered the basic concept of a transaction, what the ACID properties are and how they specify transactional behavior, and why you might use transactions. This time, we’ll talk more specifically about what it’s like to use a transaction, and how the contracts it provides allow us to write data in a reliable fashion.

Programming With Transactional Systems

Commit and Rollback

Transactions either commit or rollback. Until a transaction is committed, it is assumed none of the work it has done is saved. Once a commit signal is issued by the application (either through an API call, or by a container), this work is actually performed by the transaction processing engine that’s being used. If for some reason the commit fails due to an error scenario, or some other runtime exception occurs, we assume that the integrity of the transaction has been compromised and the transaction rolls back, removing any work done up to that point. When a rollback occurs, the transaction must be resubmitted. (continue reading…)

Preface

This work came out of an lack of consistent, cohesive documentation for beginners on transactions. Similar material does exist, but much of it suffers from either being hard to find, scattered and spotty, or not written at a basic enough level where prerequisite knowledge is not required in order to understand the material covered. Over the course of this series of articles, we’ll talk about what concepts you need to know in order to effectively and correctly make use of transactions in your applications. This series of articles is written as a set of core concepts to understanding the basics of transactions, and is intended for junior to intermediate level developers, but my hope is that others will benefit from this series as well. As always, feedback is greatly appreciated.

What is a transaction?

Etymology

The word transaction comes from the Latin word transactionem meaning “an agreement, accomplishment,” which itself comes from the past participle of the verb transigere, transactus, meaning “drove or carried through.”

Transactions defined

The word’s definition is typically related to business or economics, meaning a single business deal, or an exchange of goods between two parties. Most introductions to transactions use an example of debiting one bank account and crediting another. When we remove funds from one account, we need to make sure that they are deposited into the other. If something fails (sufficient funds do not exist in the account being debited, or the account being credited has been closed) then both accounts need to be returned to their original state before the exchange began. This is actually a very good example, but how does that apply to software?

(continue reading…)

The following scenario plays out a lot when I pair up with people, so I thought I’d distill it down and write it up for future reference. I think teaching lessons through scenarios could make for an interesting series of articles, and I’m sure others have equally interesting experiences to share.

I’ve tried to condense this down to just the steps vital to understanding the underlying problem (though this is certainly not the only way to get there) and introduce some terminology (providing links, even if deferring to google) along the way. I hope these help out aspiring or new developers.

(continue reading…)

In a recent tech talk, I watched Miško Hevery propose an interesting challenge to his audience: start a toy project and try to write the code with no if-else or switch blocks at all. None at all?  Before thinking about how to do this, why would you want to do it in the first place?  On the surface, it may seem to the unassuming a bit counter-intuitive.  Comparison-based branching is at the heart of programming, and the concept of an if-else or switch block is almost universal, existing in most every programming language ever devised.  What’s Hevery’s agenda with this exercise – and what can possibly be gained from trying to write a program without branching entirely?

(continue reading…)

I recently read Scott Leberknight‘s “Can Java Be Saved?” with interest and started typing up a response.  As Scott’s article was a bit lengthy, so became the comments I had in response.  In excess of 1000 characters, which JRoller told me was spam when I finally tried to post it.  I’m still never surprised to see that happen to my writing.  Anyway, I’m probably just an oaf, but I didn’t see Scott’s e-mail listed anywhere on his site (probably another spam-deterrent choice) so I thought since I spent more than a few minutes on it, it’d be appropriate enough to post here and link it.  Sorry but I don’t have the energy to evolve this into a more formal post, perhaps I will at a later date.

(continue reading…)

Back in April, there was an interesting article quoting Ron Jeffries et al on InfoQ looking at code reuse from an agile perspective. The conversation steered toward explaining reuse as a concern that is very expensive, looking at it from a top-down, “enterprise”-wide lens.

But is code reuse a black and white issue? My contention is there are varying degrees of reuse that are often neglected on a microscale within an even moderately-sized project. If the code you produce isn’t going to be reused, is it even going to be looked at? These are similar problems with similar solutions. (continue reading…)

Update: I cleaned up the example based on Rogerio’s comments.

Recently I stumbled onto JMockit and have been pretty impressed with the flexibility of the approach it takes.

Many mocking frameworks seem to take an elitist attitude toward testable code, not attempting to solve certain problems in favor of guiding one toward a more testable design. It appears JMockit is a response to this. (continue reading…)

As of JUnit 4.4, if you happen to peek into the distributed JAR you’ll notice something a little off: in addition to the org.junit.* packages there is this a funny-looking org.hamcrest.* package sticking out like a sore thumb. You may have seen other projects pick up a dependency on Hamcrest lately as well, and I bet you’re wondering what it is. Let’s get to the bottom of it. (continue reading…)

Update: A great article on OSGi popped up on Javalobby today. Check it out.

I haven’t yet written any thoughts about OSGi but it’s something that’s increasingly found its way on to my radar over the past year and a half or so. I’ve been doing a little bit of reading and research on it lately, (a quick introduction can be found via Adrian Colyer’s talks on InfoQ about it). Needless to say it’s got me excited. Really excited – to the point where I’m catching myself geeking out uncontrollably like Quagmire from Family Guy. What’s got me all giggity? (continue reading…)