Handful of sand

One of the sore points of using Hibernate for bulk inserts was that the sequence support wasn’t good enough (we were able to circumvent most other issues). If you have used Hibernate with sequences prior to version 3.2.3 you would have noticed the series of calls it makes to the database server to generate the sequence values per insert. This was such a grievance that we ended up doing plain JDBC inserts whenever we did inserts in bulk (which is ugly and difficult to maintain). I am glad i don’t have to do that anymore.

With 3.2.3 we have more adaptive sequence strategies that are better performing as well. I am talking about the SequenceStyleGenerator. So how does that improve performance. Say for ex, we have to perform a hundred thousand inserts. With this generator, we can reduce the database calls to retrieve the sequences to a negligible number, say for ex 10 in this case. All we need to do is configure like below

<generator class="org.hibernate.id.enhanced.SequenceStyleGenerator">
	<param name="sequence_name">MY_ID_SEQ</param>
	<param name="initial_value">100</param>
	<param name="increment_size">10000</param>
	<param name="optimizer">pooled</param>
</generator>

On seeing ‘pooled‘, Hibernate is going to use the database retrieved sequence value as the starting point and optimize by incrementing in memory. When the increment_size is exhausted, it then goes to the database to get the next sequence value and continues the in-memory incrementing. This also means that we use the same increment_size in the DDL for the database sequence.

I called it adaptive because it can adapt to databases that lack support for sequences, Hibernate will just use a table to mimic the same without additional configuration.

Now if you are using Spring Batch, you would want your chunk commit-interval to echo this value as well (or a multiple of this increment).

From the very first days of my Flex programming experience one of the interesting requirements has been to trigger a chain of Cairngorm events. The way i see this usually met is by throwing the next event on the response handler of the previous event.

I dislike that simple approach for a few reasons. The primary reason is that its difficult to understand what all is happening without following each and every responder. Its not that easy to maintain such code.

A few months back it struck me that what we need is the concept of Flows. When chaining a series of events, we are actually trying to define a flow. I hacked up a few classes, refactored a bit and finally had a working base from which i could extend. The following is how a flow looks

public class UserInputsChangedFlow extends Flow {
		override protected function getActions():Array {
			var actions:Array = new Array();
			actions.push(performSave);
			actions.push(refreshSummaries);
			actions.push(refreshOutputs);
			return actions;
		}

		private function performSave():void {
			inputViewModel.saveChanges();
			//this step's completion will be notified by the inputViewModel itself
		}

		private function refreshSummaries():void {
			summaryTabModel.refresh();
			//we don't care about the response
			actionCompleted(true);
		}

One cursory glance at the getActions() method tells me what all is involved in the flow! Note that each of those action methods give me the option of deciding what i want to do next. Those methods for ex could abort the step by directly calling actionCompleted(true/false).

So how does someone start the flow? As you can see, this class extends from my Flow class, which adds some features like executing the actions in sequence, notifying a completionCallback function, allowing us to terminate a flow etc. So for ex, my view/model could trigger the flow this way.

new UserInputsChangedFlow(model).execute();

I liked this approach, primarily because its now easier to understand whats going on without much effort. We all want to be lazy anyway right?

Another neat thing is that the flow is now a typed thing instead of floating around like a ghost scattered across the code. Its now a first class object.

Another advantage is that its easy to add new features. For ex i added an enhancement to terminate the flow in the middle. If the flow consists of a series of expensive steps and we need to stop it in the middle, we can do flow.terminate(). This will stop the flow at the next possible point, ie before the next step returned by getActions() executes. This is especially useful if we allow the user to keep on changing inputs thereby causing a flurry of requests (and typical Flex apps give the user such freedom), which otherwise we had no control over.

A less flexible approach i had come up with a couple years back was the concept of ChainedEvents that encapsulate all the events in a chain and are executed in that order provided you call the special ChainedEventDispatcher (a wrapper on top of CairngormEventDispatcher) to dispatch the chained event. But it was not possible to intercept the execution of the chain to avoid a step or abort the chain etc.

One of the domain entities in my application is a concurrency controlled resource. To give an example, say a NoteBook to which only one user can write at a time, by acquiring a lock.

So i thought of introducing a Lock abstraction to hold lock specific information (who owns the lock, since when). Now a Lock can either soft or hard. A Soft lock held by one user can be acquired(usurped) by someone else. A Hard lock has to be relinquished by the lock owner himself.

My initial approach was to use an enum to realize the lock type. So my Lock abstraction looked as below

public class Lock {
    private boolean locked;
    private User owner;
    private DateTime since;
    private LockType type;
..............
    public static enum LockType {
        SOFT, HARD;
    }
}

When i was typing out the enum definition, it struck me that i was not giving enough importance to the lock type, after all thats what defines a lock. Something like below is what i thought of

public class LockBase {
    private boolean locked;
    private User owner;
    private DateTime since;
....
}

public class SoftLock extends LockBase {
//empty
}

public class HardLock extends LockBase {
//empty
}

So which one did i go with?

I went with the first option of keeping the type as an attribute. I didn’t see any need for the derived classes SoftLock, HardLock because Lock does not have much functionality that differs by the type. And the choice could have been different if Lock was a key abstraction (and not just an anemic value object)

I wanted dynamic configuration of my logback TurboFilter and i couldn’t find a good way to configure my logback TurboFilter through logback.xml. My requirement was to configure the filter based on a property from a properties file. I could have read the properties file in the filter class but i instead decided to use my Spring configuration for wiring in properties. To reap that benefit, the filter had to be a bean in the Spring context. Something like this when configured in XML

<bean id="turboFilter" class="com.nielsen.mmp.fw.logging.DynamicLoggerDisablingFilter">
    <property name="disabledLoggers" value="${disabledLoggers}"/>
</bean>

Now all i needed was some glue code that would make logback use this filter. Its been quite a while since i saw a need for a Spring BeanFactoryPostProcessor. I added a simple filter discovering post-processor that would discover all the TurboFilters defined in the Spring context and let logback know.

Map filterBeans = BeanFactoryUtils.
                            beansOfTypeIncludingAncestors(beanFactory,
                                                    TurboFilter.class);
    for (TurboFilter filter : filterBeans.values()) {
        LoggerContext loggerContext = (LoggerContext) LoggerFactory.getILoggerFactory();
	loggerContext.addTurboFilter(filter);
    }

Because we have hierarchical BeanFactories i had to use this BeanFactoryUtils.beansOfTypeIncludingAncestors(…) method. The usual BeanFactory.getBeansOfType() checks only in that beanFactory instance. It does not go through the parent beanFactories.

I wish Joran had a way (documented) to use values from properties file when configuring. Something like the following would have been neat.

    <configuration>
        <properties id="props" source="my-app.properties"/>
        <filter id="myTurboFilter" class="x.x.x.MyTurboFilter">
              <myFilterProperty>$props.propertyKey</myFilterProperty>
        </filter>
    </configuration>

Edit:
So i was mistaken. Joran does support properties file based customization just the way i had outlined. But, but, but, i don’t see it allowing property file overriding (ie a property file overriding the base property file) which is what we needed for our app. So my post processor is still going to be useful.

Checked out WebSphere 7.x. EJB container can no longer be disabled. Its atleast less misleading now, though the EJB container cannot still be disabled.

I still remember the call we had with WebSphere reps quite a few months (or was it an year) back. One of my questions was about the inclusion of OSGi and the answer was in the negative. I find from their release notes that WebSphere 7 uses OSGi in its server architecture (even though its not exposed for applications to benefit from, which would be a bigger leap i assume).

WebSphere 6.x appears to be tightly linked to its EJB container so much so that we can’t start the server without the EJB container. The administration console does allow preventing the EJB container from starting. But then on server bootstrap Scheduler service complains that it can’t find the EJB container. And guess what, the scheduler service cannot be disabled in 6.x, at least in a documented way. In a nutshell, my server start up failed. I had to go hand-edit the server.xml to be get my server working again.

Why should environments running plain web applications have to bear with the EJB container footprint unnecessarily? And what could be the reason behind introducing a dependency on a nested container for the server to work normally. And how about actually telling the user they shouldn’t be doing this action because their server won’t startup after that?

We woke up one saturday morning to find that one of our Flex application screens quit working. On further analysis, it unravelled that the problem would occur only on Saturdays. Good luck selling the product to a customer with that bug

We deal with time ranges in our application. An instance of our Period class represents a time continuum between a start and an end. Something like below

public class Period {
    private var _start:Date;
    private var _end:Date;

    public function get start():Date {
        return _start;
    }
    public function set start(dt:Date):void {
        _start = dt;
    }
...
}

One special block of code tries to go through our known periods and tries to determine which period the today’s date falls in. And it didn’t find any when today happened to be a Saturday, because all periods ending on saturdays were being translated to Fridays thanks to timezone conversion

A couple things were contributing to the problem
1. Lack of date-only abstraction in Java (time has to be there always)
2. Flex, BlazeDs dutiful timezone translation when a date is sent from Java to ActionScript

In normal applications wherein we want time component represented in a timezone dependent manner, all these are just what the doctor ordered. For ex, in a trading application if a trade was submitted at 15:00 EST, then a user in CST timezone should see that as 14:00 CST. The above 2 will make it partially possible (partial because there’s more to accurately storing a timezone dependent time than just these). But in our application we did not want the time component, period. Our date was a pure date. Java does not have this concept, so a pure date is a date with 12:00 AM as the time (and a default timezone of the OS). Even that is fine with us. But when that date is received in Flex for a user in CST, Jan 1 12:00 AM EST becomes Dec 31 11:00 PM CST. And the only thing that mattered got altered, i mean the date.

The following were the solutions we could think of

1. Use a custom type to store timeless dates (timeless ). There would be one custom type in Java and a mirror in Flex. But then we lose all the date API support (or whatever silly support) that is available. We can’t extend the Date class in Flex, its final. And we do not have control over serialization of the primitives and default types, one of which is Date.

2. Manipulate the date’s time component in the Flex remoting layer to account for the difference between the client and server GMT offsets. This is a cool solution but is a bit hacky. For ex, we would add 1 hr in the above case to Dec 31 11:00 PM CST to get Jan 1 12:00 AM CST. We have to do this on the way in and the way out.

3. Use a custom type, but use it just for transmission: This works when we have an abstraction on top of dates, like our Period which had a startDate and endDate. The rest of the application depended on these startDate and endDate attributes. For transmission, we added 2 parallel attributes, transStartDate and transEndDate, which use the custom type. The accessors were intelligent enough to convert between transmission date and the regular date.

We went with #3. If we had to transmit a date by itself we could use the TransmissionDate custom type to do that. #2 was a strong favorite, but then #3 was cleaner, way simpler and all in one class; basically had the symptoms of a better solution.

So on Flex side our Period class now looked like this

public class Period {
    private var _start:Date;
    private var _end:Date;

    public function get start():Date {
        return _start;
    }
    public function set start(dt:Date):void {
        _start = dt;
    }

    public function set transStartDate(dt:TransmissionDate):void {
        _start = new Date(dt.getYear, dt.getMonth, dt.getDate());
    }
    public function get transStartDate():TransmissionDate {
        return ...
    }

All existing code was safe and didn’t need to change. This solution also helps highlight the importance of proper abstractions. A couple of getters, setters and two new classes and the problem was behind us.

There are quite a few blogs that talk about this issue. For ex this one

Inspite of their massive relevance to our everyday lives, Dates and times are some of the poorly understood concepts when it comes to programming and APIs. In every application that we build that deals with time, we will find something quirky, guaranteed. Its fun.

If you didn’t have sub-tasks enabled in JIRA when you connected Mylyn, then Mylyn won’t pick up the feature automatically when its enabled in JIRA. For this to work, just right click your JIRA repository in the Mylyn Task repositories view and ‘Update configuration’. Mylyn will then start supporting creation of subtasks from the Tasks view.

Surprisingly Mylyn will recognize subtasks and display them grouped under the main task even without this capability enabled. But you won’t be able to update them or create new sub-tasks.

I have been through 2 major versions of Mylyn. My experience with Mylyn has been quite pleasant, i feel its one of the most well-rounded and perfect plugins i have used in Eclipse (of late). It just works !

I just finished using Spring Batch for an application. I would definitely recommend Spring Batch for batch environments. Here’s what i liked and what i didn’t Read more…

This is again one of those rare things that we don’t encounter often. You have 3 columns in a table which you want to represent in your domain class as a list of values (3 in this case). Hibernate’s collection types won’t cut it because there is no association table. You could use a custom user type that transposes the column values into a list at the time of store/retrieve. But what if the values that go into the list are more exotic? What if they have associations to other tables? I came up with 2 solutions for this. Read more…