Andreas Schaefer's Blog

Deployment Archives

Patterns: Not with Me

Yes, I have to admit I do not use patterns and I hardly know any of them. Seven years ago I bought the book "Patterns in Java" and looked at it only to find out that most of them I already knew and had already applied. So this book went to the shelf to remain there until, I think, it was recycled. So far I never needed patterns to do my job and for most part there are no patterns that deal with multi-threading, class loading and bytecode manipulation (AOP).

But, no, I do not condem nor to I encourage developers to avoid patterns because they can improve their coding and communication skills. Nevertheless I think that everyone has to try hard to understand the background and motivation of a pattern rather than just applying them unchallanged. A pattern is like a cook book recipe and you master cooking when you can change the recipe or mix recipes to a new one and the meal still tastes great because then you understood the recipe rather than just followed the list of ingredients and the instructions.

The only way I used pattern lately was to check out if a company I had a job interview with was really inovative by stating that I do not use patterns. If a manager or a team lead could not accept that I went beyond the need for patterns then it told me that they cannot let developers run loose like I was used in open-source projects and they were quite conservative in handling a project. I cannot imagine that Steve Jobs (yes, I hate his arrogance but like his management style) would have followed a pattern when designing the iPod or do you?

Finally, in some of these interviews I was asked what was my favorite pattern which I find quite an odd question because I would apply a pattern that suites the problem rather than try to apply my favorite pattern. There isn't a HAMMER pattern that makes everything to a NAIL luckily otherwise most of us would be out of a job.

Have fun - Andy

jUnit to the Rescue

I was just recently faced with taunting task to revamping the transaction handling of the J2EE server without breaking it but improving performance and removing any resource leaks. Already two developers tried to do this but had problems to understand the existing code in the first place and so I failed, too. If we could not improve the code we had to dump the implementation and start all over again. Now just a few weeks before shipping I had to rewrite a central component without wasting other developer’s time and/or delaying the project. Lucky me jUnit came to the rescue. Instead of just starting to write a new implementation and then testing it I decided to write a test suite around the currently working code, replace the code and rerun the test suite ensuring that I did not break anything. Finally I had a chance to use test driven development (TDD).

As easy this sounds as difficult it was to implement. I spent around the same time for writing the test suite that to rewrite the transaction code but at the end testing was a breeze. The first hurtle was to decide how to test a transaction implementation because I did not want to rely on a DB, JMS etc and their side effects. So I wrote a fake XA resource that used JMS without transactions to trace the interactions with the transactions, various EJBs and 100+ tests. The first benefit from writing the test suite were a much better understanding of the transaction handling and its interaction with XA resources. At the end testing the new code was easy, straight forward and I missed one bug so far. The tests also made me very confident to put the code in the release branch without fearing to work on weekends just to fix undetected bugs.

So I have to give jUnit and TDD two thumbs up and see a beautiful friendship in the future. Nevertheless I have two little requests to the jUnit folks:

1. A way to write a message to the output file on a per test basis in order to write a description or other information out that later can be read and incorporate in a test suite report.
2. Currently there is only a successful or failed (failure or error) test result possible but sometimes it would be nice to keep non-crucial failures available but they should not fail the test suite. These warnings could be reported and even have a stack trace but would be considered a success. Examples of a warning could be a bug in a particular JDK or third party library that needs a work around but as soon as this is fixed the workaround should be removed or bugs that are postponed etc.

SLSB -> SFSB: Meaningless ?

A colleague of mine just pointed out that in Richard Monson-Heafel’s EJB book (3rd edition) configurations like Stateless Session Bean (SLSB) -> Stateful Session Bean (SFSB) are considered meaningless. I understand that any EJB book cannot deal with all possible scenarios otherwise you need a truck to take the book home but I find it too interesting not to talk about. Luckily I can discuss in my weblog any scenario I like and hopefully I can show you that rules are meant to be broken even when the result only confirms the rule.

Let us assume that we have a SLSB that has at least one business method in it that is quite elaborate and performs many tasks. In addition we want to have multiple resources or a non-standard resource wrapped in an EJB like a raw TCP/IP socket. Because the resource(s) should participate in a transaction and must be opened before usage and closed at the end it cannot be a SLSB because we never know what instance we get back on each invocation due the fact that the pool is returning the next free instance before a method is invoked. The only way left is to use an SFSB because a particular instance is available to the SLSB instance during the entire method call and so at the end I can close the resource(s) or do any other cleanup task. In this case the SLSB method does represent a client towards the SFSB even thought the life span of the SFSB is not that long.

Now one could object that I could just use a plain Java class instead of wrapping the resource(s) into an EJB but an EJB can use JNDI environment variable to specify setup properties, I can look it up very easily on a JNDI server and use an EJB reference in the Environment Naming Context (ENC) of the SLSB. Finally I can deploy the EJB in a separate application and use it throughout the server. One could also suggest using JCA instead but this could either overkill or what is wrapped in the SFSB does not adhere to JCA specification.

I want stress the fact that this rule should only be broken when there are compelling reasons to do so and you checked out the other options like keeping the code in the SLSB, creating a plain old Java object or using JCA and then selected the best solution that does not only fit you best now but also in the (near) future.

How to Handle Permanent Exceptions after EJB Deployment: a Proposal

Finally I found time for a technical log here at Java.net. This time I want to discuss a shortcoming of the EJB specification and how they can be fixed to make the life of EJB developers and application server administrators easier and the deployed applications more robust.

Originally the EJB specification assumed that the applications are deployed at startup of the application server and the environment remains stable for the time the server is up. With the broader acceptance of the J2EE application servers the dependencies between remote servers (DB, application servers, JMS etc) grows and a successful deployment does not mean that an application will run smoothly all the time. In some cases application server are just used to host application on the user’s computer and there is not full time administrator on duty.

Let us assume that an application contains one or more message driven beans (MDB) and they invoke other EJBs or resources to help execute the handling of a message. Now a resource used is becoming unavailable for a longer period of time and the message cannot be handled anymore. In the current specification then only thing the MDB can do is to either swallow the message and therefore lose all the pending message on the destination the MDB is registered on or it can rollback the message causing the server to resend the message immediately. The second option of course will put a drain on the server because every message will be resent until the message could be handled again or the server is putting the message away in some sort of a dead letter queue. Just imagine that a destination contains thousands of messages which are resent multiple times just to end up in a dead letter queue. What a waste of resources, isn’t it.

A similar problem occurs when a client access a stateless session bean (SLSB) because the SLSB instance is not created when the “create” method is invoked on the home interface but somewhere between the deployment and the first invocation of a business method on the SLSB instance. This means that any exception in the “setSessionContext” and “ejbCreate” method is not available to the client.

Both problems can be solved if the EJBContext would allow the EJB to inform the server about an unrecoverable error with a message and a Throwable instance. This allows the server to take the EJB and/or the entire application in question down and return an appropriate EJB- or RemoteException to a caller to inform about the original problem. The server then can inform the administrator about the problem or can try to restart the EJB/Application periodically (in the case of MDBs). Such a hook in the EJBContext could look like this:

public void reportException(String message, Throwable cause, int severity, int hintForServerHandling);

This work is licensed under a Creative Commons License.