'. '


From APIDesign

Jump to: navigation, search

Modular applications assign its every piece certain role. One module shall provide API for access to storage, one for displaying wizards, etc. Other modules depend on such API modules and use them get the data from the storage or display their wizard dialogs. The intuition clearly indicates that by wrapping all the complexity of dealing with storage into a separate module, the overall complexity of the code is simplified.

Still, it is important to put and enforce certain restrictions on the interactions between various modules. For example it can be extremely dangerous with respect to synchronization and deadlocks to allow those who implement storage to try to display dialogs or wizards. The access to screen may already be occupied by someone else, yet the storage access needs to work for everyone running on background. When you are supervising such modular system finding and preventing such inverted dependencies that violate overall assumptions is one of the biggest priorities.

There are various extensions to NetBeans Virtual File System library,
including support for CVS, Subversion or Mercurial. To deal with VCS
is slightly harder then traditional task of regular file system. Sometimes
they need to make decisions and they need to ask user questions. Indeed this
was very deadlock prone and needed to be prevented and fixed.

Simplest fix, especially if you own both APIs is to set some ThreadLocal variable whenever a method from storage API is on the stack and whenever one tries to show a wizard or dialog verify that this ThreadLocal is not set. If it is, rise an exception. This is simple, yet it feels like quite a brute force hack than a recommended pattern.

As such I was very pleased to see Srini Penchikala's presentation describing use of AOP for the same task. Instead polluting both the APIs with ThreadLocal tricks and making them semi-aware of each other (wizard do not need storage otherwise), one can define one or two aspects externally and achieve the same.

For preventing these kinds of unwanted compile or runtime dependencies the AOP seems to be perfect. Get more inspiration by Srini.


Personal tools