appleCart.upset()

Test Driving a ThreadLocal Implementation: Part 1

2010-06-20T23:03:00.023-04:00

A typical system needs access to variables or resources of varying scopes. Those resources are accessible from many providers, including singletons, configuration objects that read external properties files, and factories that rely on configuration files for dependency injection frameworks. Some resources should be globally reachable by any object in the system. Other resources, however, should be restricted to one object, a trusted subsystem, or even a single thread.

In the case of a thread, an oft-used solution in the Java world is the venerable ThreadLocal. Some transaction processing approaches in multi-threaded systems, for example, employ a static final ThreadLocal to make a unique transactional resource available to any object in a thread. In particular, developers using pre-3.0.1 versions of Hibernate often used this approach to propagate a Session to data access objects.

We could use ThreadLocal in creating a framework based on the UnitOfWork pattern. In a layered system that uses the framework, we could propagate a UnitOfWork object to a Repository without muddying the Repository interface. It's fairly easy to visualize how all this might work. An application object could tell a UnitOfWorkManager to create a UnitOfWork for managing a transaction boundary. Repositories could call upon the UnitOfWorkManager for the current UnitOfWork to support implementation details (e.g., using a JDBC Connection).

Assume in a earlier unit test, we discovered the applicability of the UnitOfWorkManager and UnitOfWork concepts. We ultimately decided to create a UnitOfWorkManager interface with implementations that could be injected into other objects.

Here is our interface. We'll skip the details of the UnitOfWork itself.



package example;

public interface UnitOfWorkManager {
    UnitOfWork create();
    UnitOfWork current();
}

Let's test drive a UnitOfWorkManager implementation, proving that each thread can create and access a unique UnitOfWork object from one UnitOfWorkManager.



package example;

import static org.junit.Assert.*;

import org.junit.*;

public class UnitOfWorkManagerTest {
    private UnitOfWorkManager manager;
    private UnitOfWorkConsumer firstConsumer;
    private UnitOfWorkConsumer secondConsumer;

    @Before
    public void setUp() {
        manager = new MyUnitOfWorkManager();
        firstConsumer = new UnitOfWorkConsumer(manager);
        secondConsumer = new UnitOfWorkConsumer(manager);
    }

    @Test
    public void createsUniqueUnitsOfWorkPerThread()
            throws InterruptedException {
        firstConsumer.consume();
        secondConsumer.consume();
        assertNotSame(firstConsumer.newWork,
                      secondConsumer.newWork);
        assertNotSame(firstConsumer.currentWork,
                      secondConsumer.currentWork);
        assertSame(firstConsumer.newWork,
                   firstConsumer.currentWork);
        assertSame(secondConsumer.newWork,
                   secondConsumer.currentWork);
    }
    
    private class UnitOfWorkConsumer extends Thread {
        final UnitOfWorkManager manager;
        UnitOfWork newWork;
        UnitOfWork currentWork;

        UnitOfWorkConsumer(UnitOfWorkManager manager) {
            this.manager = manager;
        }

        @Override
        public void run() {
            newWork = manager.create();
            currentWork = manager.current();
        }
        
        void consume() throws InterruptedException {
            start();
            join();
        }
    }
}

Finally, we have our implementation.



package example;

public class MyUnitOfWorkManager implements UnitOfWorkManager {
    private static final ThreadLocal<UnitOfWork> localUnitOfWork =
        new ThreadLocal<UnitOfWork>() {
            @Override
            protected UnitOfWork initialValue() {
                return new UnitOfWork();
            }
        };

    public UnitOfWork create() {
        UnitOfWork unitOfWork = current();
        prepare(unitOfWork);
        return unitOfWork;
    }

    public UnitOfWork current() {
        return localUnitOfWork.get();
    }

    private void prepare(UnitOfWork unitOfWork) {
       //Not shown
    }
}

Typically, objects in a static context are accessed via static methods. We don't do that here because we are implementing an interface, and our static access is an implementation detail. Incidentally, we'll need to prevent returning an unprepared UnitOfWork if a consumer fails to first call create(). We may be able to eliminate create() altogether and override ThreadLocal.get() to handle proper initialization when current() is called. This scenario is beyond the scope of our example.

In any event, we've succesfully test-driven a simple implementation of our original goal. The test, however, could stand some minor refactoring, which we'll take up in a later post.

The Laws of WebSphere RAD

2010-06-20T10:39:00.003-04:00

Parkison's WebSphere RAD Law: RAD's demand for resources expands to consume all available RAM and CPU.

Hofstadter's WebSphere RAD Law: It takes longer than expected for RAD to do anything, even when accounting for Hofstadter's WebSphere RAD law.

Ralph and Ray Separated at Birth?

2009-12-06T10:00:00.003-05:00

Ray Manzarek of the Doors

Ralph Johnson of GoF

A Free Market for Health Care

2009-07-16T19:32:00.004-04:00

A former co-worker of mine suggested on his Facebook page that a solution for health care is a 2% income tax. Being a free market capitalist, I retorted that a completely free market for health care would solve our problems. Another person chimed in saying that the free market failed for the financial, airline, and automotive sectors. I felt obligated to offer this reply:

There is no free market in any of the sectors you mention. The financial sector, for example, is among the most heavily regulated industries and it crumbled. A free market in a truly capitalistic system would allow any organization within those sectors to succeed or fail on its own. That did not happen. The government bailed out their friends in the financial and automotive sectors in a fascist, mercantilistic system, using the money of future generations.

While the FAA still heavily regulates it, the airline industry was partially deregulated in 1978 (government removed price controls of fares). Look what has happened since then: There are low cost carriers such as AirTran and Southwest Airlines, making flights cheaper for everyone.

A purely free market for health care would open up all kinds of options for insurance and medical services. Consumers would choose the best plans that would work for them with regard to cost and services. Some people would buy catastrophic-only plans and pay directly for routine care. Others might purchase more comprehensive plans. Finally, in a free market, there might be more alternatives to insurance outright. Even now, for example, many doctors are providing concierge models that allow patients to see a doctor at almost any time for a range of services. Unfortunately, however, insurance and medical care are highly regulated by the federal government and individual states, increasing the cost to all.

With a government run or dominated health care system, there would be fewer alternatives that would otherwise be created by capitalism. There would be
either a severely hampered or no price system at all that demands providers and payors offer care and payment more efficiently (current regulations have brought this about today). Taxes will be raised, health care will be rationed, and you won't be able to do anything about it. Here is a taste of things to come:

Massachusetts in Suit Over Cost of Universal Care
CBO Chief: Health Bills To Increase Federal Costs

As an example with the universal coverage in MA, health care is already being rationed. There are plans to remove legal immigrants from the system. Today on National People's Radio (NPR), I heard a story of a legal immigrant who has cancer. He's about to be removed from coverage. People complain if private insurance drops coverage, but it looks like universal health care has effectively rationed service to some people. We don't need this disaster on a grand scale.

Excellent Posts on Load Balancing

2009-03-20T20:36:00.004-04:00

This and this are must reads on the elements of load balancing.

Continuous Integration (CI) Needs No Standards

2009-03-04T18:17:00.007-05:00

In his CM Crossroads article, Bob Aiello postulates that CI has problems, "... many of which could be solved (or at least made better) by adopting well-established industry standards (e.g., IEEE, ISO etc.)." Mr. Aiello never proves his supposition. Of the "many" purported CI problems, he writes of only one: The creation of unit tests. The IEEE 1008 Unit Testing Standard, he says, will help developers in this pursuit.

Are such standards really necessary for any aspect of CI? With regard to writing unit tests, there are many excellent books on overall approaches, tools, and patterns. Moreover, as for CI servers, the open source and commercial worlds have been providing successful products for almost a decade. The popular servers can work with many different source code repositories, such as Subversion and Git, and run common build tools, such as ant and rake.

CI is doing just fine, thank you very much.

Rcor is Now Ruby-Concordion

2009-02-17T20:03:00.005-05:00

Rcor, a wonderful acceptance testing tool based on Concordion, has just been renamed Ruby-Concordion. Please check it out. You can get the latest gem from the Google download page or from RubyForge. Better yet just install it directly:

gem install concordion

Double Ruby

2009-02-12T20:47:00.013-05:00

Now that I'm beginning to use Ruby for more than Hello World programs, I started searching for a great mocking framework. My search brought me to Bruce Tate's overview of Ruby mocking frameworks, which illustrates mocha and Flex Mock. I noticed that both frameworks require the use of symbols to stub method calls. I much prefer the approach that mockito, my favorite Java mocking framework, takes: Stubbing method calls via calls to the methods themselves rather than string representations thereof. This technique makes tests easier to write and maintain.

I stumbled across RR (Double Ruby), a framework that may be Ruby's answer to mockito. It supports many, if not most, of the approaches to Test Double. I happen to be interested in the stub approach and created a variation of the tests in Bruce's article.

Here is what I came up with:


require 'test/unit'
require 'rr'

class DoubleRubyTest < Test::Unit::TestCase
 include RR::Adapters::TestUnit

 def setup
   @document = stub_document
   @view = View.new(@document)
 end

 def test_view_prints_and_remains_open
   stub(@document).close.returns(false)
   assert(@view.print)
   assert(!@view.close)
 end

 def test_view_prints_and_closes
   stub(@document).close.returns(true)
   assert(@view.print)
   assert(@view.close)
 end

 private

 def stub_document
   stub!.print.returns(true).subject
 end
end

class View
 def initialize(document)
   @document = document
 end

 def print
   @document.print
 end

 def close
   @document.close
 end
end

Notice the stub_document method. The single line of code creates the stub and mocks the print method in one swoop. The subject method returns a reference to the mock itself.

Per the release notes, the framework seeks to make mocked code "more scannable." In my case, this scannability helped me to do a reasonable rename refactoring in NetBeans.

While my example created a stub based on no particular class definition (an empty object), the framework does allow you to stub objects of specific classes.

With its wonderfully terse syntax and variety of Test Doubles, this is one framework you should soon evaulate.

rcor 0.8.7 Released

2009-01-28T18:54:00.000-05:00

rcor 0.8.7, a Ruby acceptance testing tool based on Concordion, has just been released. I've had the pleasure of making a few minor contributions to rcor and am starting to use it in anger at work. Give it a try.

Sad Commentary on the Purpose of Domain Objects

2006-10-11T14:12:00.000-04:00

I'm reading the book Pro EJB 3 Java Persistence API. I highly recommend this book to learn the JPA. When I came across the following passage about unit testing JPA entities, however, I was dismayed but not suprised:

Entities themselves are unlikely to be extensively tested in isolation. Most methods on entities are simple getters or setters that relate to the persistent state of the entity or to its relationships. Business methods may also appear on entities but are less common. In many applications, entities are little more than basic JavaBeans. (p. 357)

In my own application development, entities are the domain, or business, objects. Hence, in my warped world a domain object must have sophisticated business methods that affect its state. I thought state and behavior are supposed to be coupled. From the sheer number of procedural systems masquerading as object-oriented, I must be in the minority. I guess I need to forget about objects. I should change my blog name to the following:


if (appleCart.getState() == AppleCartState.NOT_UPSET) {
    appleCart.setState(AppleCartState.UPSET);
}

Should Agile Be Imposed?

2006-10-10T16:36:00.000-04:00

There has been some recent buzz regarding Martin Fowler's blog about the imposition of agile development. In general, I agree with his view. However, there are situations that could dictate otherwise.

What if management is trying to transform the way the organization does business? In fact, management is obliged to make decisions that change the organization for the better. Those decisions may indeed impact members of the organization on a daily basis.

For example, a company's revenues have been falling for 5 consecutive quarters. With increasing costs, profits are becoming losses. The company is losing customers. Management determines the business model is flawed and studies alternatives. They conclude that lean production may increase the likelihood of survival and prosperity. They want to apply lean thinking to all aspects of the business from logistics, to inventory, and to software development.

A commissioned group of developers and managers conclude an agile software process may be an appropriate component of the lean business model. Currently, the organization uses a waterfall software process with which many participants are quite happy. The process, however, is chock-full of prescriptive procedures and deliverables that a value stream analysis suggests are wasteful. Moreover, the process has led to over-budget software that fails to solve current business problems.

In this case, someone must make changes. While there are many participants willing to use agile, there is much resistance. Some key participants are even threatening to quit if they are forced to use agile. Nonetheless, it cannot stand that the discordant will be doing waterfall and the accordant will be doing agile.

What if someone does not begin to impose change? What happens to the organization if the current poor practices are allowed to stand? Will there be consequences in the market? Are the competitors producing more quickly and making more money? If agile development cannot at least mitigate the current software problems, what can?

In any troubled organization, there are some who are perfectly content to roll around in the filth of the status quo; there are others at all organizational levels who are truly visionary and can be agents of change. Sometimes outright acceptance does not happen; sometimes finesse fails; sometimes imposition is required.

Towards Typesafe Closures in Java 5.0

2006-03-03T21:46:00.000-05:00

In my study of Ruby, I've become enamored with the concept of closures. Many a Java developer has pined for such a brilliant feature. Perhaps one day the language itself or its standard packages will provide support. What, however, could one do in the meantime?

The Collections component of Jakarta Commons offers the static utility solution, namely this class and method:

CollectionUtils.forAllDo(Collection, Closure).

Closure is an interface with an execute operation that takes an Object. Closure.execute(Object) has the nagging requirement that you must downcast the Object parameter to do something very meaningful with it, and downcasting may result in a ClassCastException.

While CollectionUtils has the advantage of using the standard Java collections, it would be proper if a Collection object could run a Closure over itself in true object-oriented fashion. If you are willing to live with your own collection class, you can do this. Moreover, you can do this is in a typesafe manner with Java 5.0 generics.

Here we have the typesafe Closure interface:


public interface Closure<E> {
    void execute(E item);
}

and the custom collection class (of course, a better name for it might be in order):


import java.util.ArrayList;
import java.util.Collection;
import java.util.Iterator;

public class ClosureableCollection<E> implements Collection<E> {
    private Collection<E> collection;

    public ClosureableCollection() {
        this(new ArrayList<E>());
    }

    public ClosureableCollection(Collection<E> collection) {
        this.collection = collection;
    }

    public void execute(Closure<E> closure) {
        for (E collected : collection) {
            closure.execute(collected);
        }
    }
    ...
}

Notice that we implemented the Collection interface. One reason you may want to do this is if you have existing methods to which you must pass a Collection. Another reason is that maybe one day Collection will actually accept closures, and, consequently, refactoring might be minimal.

Now let's see how we can actually use this.


import static org.junit.Assert.assertTrue;

import org.junit.Before;
import org.junit.Test;

public class ClosureableCollectionTest {
    private Shape square;
    private Shape circle;
    private ClosureableCollection<Shape> shapes;

    @Before
    public void setUp() {
        square = new Square();
        circle = new Circle();
    }

    @Test
    public void closureDrawsShapes() {
        shapes = new ClosureableCollection<Shape>();
        shapes.add(square);
        shapes.add(circle);
        shapes.execute(new Closure<Shape>() {
            public void execute(Shape item) {
                item.draw();
                assertTrue(item.equals(square)
                        || item.equals(circle));
            }
        });
    }
}

The cost is having to carry your own collection class. The benefit is a typesafe, object-oriented approach to a feature that Java should have now.