Archive for June, 2010

Web Project Install Wrecks

June 11, 2010

Working in custom software on web applications for a few years now and one thing which is a continual issue is project installs. Its interesting when your developing non-packaged software, the actual install process is an after thought. Projects have sprawling parts spread across the file system, install step on a application server or web server, and some set of database tables/procedures which many custom shops decide to try to enumerate out into implementation steps. This puts great pressure on the team producing the install documentation to not forget anything and someone to faithfully reproduce the steps, which means that even with a test run it can still be error prone. I think there is a thought that because the software doesn’t ship its not worth while to create automated install code to allow someone to simply install the app and the application take care of additional steps. For simple applications it certainly maybe overkill but if your moving into multiple environments for a single release which many larger projects are going to have to do, its worth the investment.

Think Thread Safety

June 2, 2010

In multi-threaded languages such as Java issues related to thread safety can be the most difficult to debug because they depend on timing during program execution. I would guess that most programmers know about thread safety but they aren’t aware of when they need to be thinking about it. The answer is ALWAYS! Many times they just assume that the framework they are working with will take care of any thread safety concerns but thats not the case. Any time you modify code or are creating new code you need to ask yourself “do I need to be thread safe?”  So why do we get caught is the pitfall today with newer frameworks and how can you tell if your being thread safe?

Pitfall: The Singleton…

With the advent of Spring and lots of other frameworks one of the dominate design patterns is the Singleton. By default for efficiency reasons many frameworks when creating objects, create only one instance that is executed on by all threads calling the code. This means your objects need to be stateless when integrating with many frameworks. For many developers this is tough because we want to make objects with lots of state, or have existing objects with state that we want to integrate into the framework with little to no refactoring. That combined with the fact that the actual call of your method will be wrapped in multiple points of indirection in many cases and it will work when you are testing in the simplest case tricks you into thinking your code is integrating properly when you are not. A through read of documentation in almost all cases for the framework fixes the matter but the reality is most folks learn from tutorials and experience first. Don’t get me wrong thread safety has and will be a concern of great significance whether or not your using singletons, but its one of the major patterns used today making it that much more important.

Thread Safe Or Not?

Now with the pitfall identified, how can you identify what needs to be changed and where possible issues are? Without going into much more detail for some specific situations that won’t be possible and I’ll avoid getting into that amount of detail for post length sake. At least I can provide a general rule you can follow to identify if a class is thread safe and once you have determined when the calling code demands you’ll be able to identify if there is an issue…

If a class has no synchronization and accesses a variable that has state that is not appropriate to share with other executions of the class, then the class is NOT thread safe.

For this rule “variable that has state” would include any variables that can be changed by code external to your class’s methods or changed by the methods internal to the class. This rule ignores usage of execution synchronization to simplify the discussion mainly. Take a look at classes like this and make sure they are being used appropriately and not concurrently by different threads.

Not being thread safe isn’t a bad thing. But when creating or updating existing code, knowing whether you need to create something thread safe or not is the something you always need to take into consideration. If you don’t know if the code calling your code will be calling it in a thread safe fashion STOP and research the callers to determine if you need to be thread safe.