Wondering About Transactions

Transactionless

A couple of years ago I was talking to a couple of friends of mine who were doing some work at eBay. It's always interesting to hear about the techniques people use on high volume sites, but perhaps one of the most interesting tidbits was that eBay does not use database transactions.

My immediate follow-up to the news of transactionless was to ask what the consequences were for the application programmer, in particular the overall feeling about transactionlessness. The reply was that it was odd at first, but ended up not being a big deal - much less of a problem than you might think. You have to pay attention to the order of your commits, getting the more important ones in first. At each commit you have to check that it succeeded and decide what to do if it fails.

I've been wondering about the usefulness of transactions for sometime and ACID in particular. One of the easiest to dismiss, suprisingly perhaps, is isolation. For example, skip list implementations ruin it as the data may change during iteration and it can easily be avoided by writing the information of one transaction to a file to be read by something else in another (either by accident or on purpose). The alternative might be something like CAS and RDF triples. Expecting application programmers to do it sounds awful however.

Also, noticed by, "Living Without Database Transactions".

A Third Way to do Transaction Management in Spring

Generally, I've oscillated between two different ways of doing transactions in Spring, the first is with declaratively using AOP and the second is programmatically throw the use of TransactionTemplate or to be really hardcore PlatformTransactionManager. I say hardcore because it's a bit more work to ensure that everything is commited or rolledback correctly.

I recently arrived at another way due to the requirements of testing the objects via interaction based testing. The AOP method makes it hard to Mock out calls as it wraps everything in a proxy and the programmatic approach seems impossible to test purely interactively (basically requiring a real TransactionTemplate). Especially as some things are classes and interfaces.

This idea combines the simple ideas of interfaces, dependency injection and either TransactionCallbackWithoutResult or TransactionCallback.

Create an interface, say "DoStuff" that has the required method to be in a transaction say, "doStuff(String stuff)". There are two implementations of this interface "DoStuffImpl" and "DoStuffInTransaction". The "DoStuffInTransaction" gets injected the "DoStuffImpl" and the "TransactionTemplate". It also implements "TransactionCallback". When it's "doStuff" method is called it sets the parameters to fields and then calls "transactionTemplate.execute(this)" and the "doInTransaction" methd calls the "DoStuffImpl.doStuff()" method.

By wiring up the "DoStuffImpl" inside "DoStuffInTransaction" your other classes can only access the transactional version. It makes interaction testing straightforward and doesn't require explicitly calling things like commit or rollback.

Spring Aspects - A Transactional Thing

I've recently been looking at transactions in Spring 2.0 - it certainly has more things to make your code sing.

The Spring 2.0 Transaction document has some useful information on using a TransactionTemplate to wrap transactional operations. Of course, the best way is Spring AOP for declarative transaction management and using Java 5.0's annotations.

There's a previous discussion of applying transactions using Spring 1.x using Hibernate in, Wire Hibernate Transactions in Spring.

Javapolis Spring Update and Maven 2.0 (see also, this Maven 2.0 article) most of talks are well worth a listen.

Articles on using the new AOP features in Spring 2.0: Typed Advice in Spring 2.0 (M2) (about finding methods in Spring AOP) and POJO Aspects in Spring 2.0: A Simple Example.

An article on JPA (Java Persistance API), Using the Java Persistence API with Spring 2.0.