Continuations

Yesterday I spent quite few time trying to solve some problem related to old data stored in the webapp session. It made me remember a similar situation few years ago, when I had hard time with the same problem (not that it just happened twice, but those two times were quite remarkable).
But there is a small difference between those two situations, a small difference that makes all the difference.

In the early days I was dealing with a kind of application similar with those online selling: a lot of pages that you must commit the information only at the end. So the use of the session, although not mandatory is almost 100% of the choice. But the application of yesterday is the opposite: it should commit the changes all the time, almost at every breath of the user; but again we are using the session.

I remember myself thinking how it would be nice and simple to get free of the session, all those synchronization problems, back button problems and so on. And now I have an application that could act like saving all the time, but still we are stick with the session. Why?

Well I don't have the answer but I guess it is just a question of old habits, justified by the performance of using the session. And that is my point: is the session the best high performance solution?

Well, I would like to have numbers about it (maybe in a future post), but it is well spread the idea that session is an enemy to scalability. It makes all the sense, but a non-session world looks like to be impossible outside of the books.

I do not advocate about killing the session, no!, but a better management of it is crucial for: a better performance application (memory leak can kill an application more easily than a slow response time) and a smooth programming (spend hours trying to find out why things do not match is not nice).

As I said in the beginning, it is just a way home though, but it deserves some kind of investigation, what the world thing about this subject. Despite of the REST way of doing things (which we can discuss later) I have found a nice third wave, something that they claim to be Statefull programming model for a stateless world: Continuations.

I would explain it here, but there is nice article at IBM which can do this job much better Crossing borders: Continuations, Web development, and Java programming.

I hope you enjoy the reading; maybe it could make you less angry next time (knowing that there is a brighter life out there).

Testing your equals methods

We all know that testing is something important. But there is some situations that writing a test code could be quite confusing.

One of this situations is how to test a equals method and ensure that all the attributes are tested correctly. Most of the time we just test if all the fields are equals or not.

It is ok, but it is far from being complete and usefull.

Here is a pattern that you can follow and it will insure that all the fields are being tested correctly:

1. Create two values for each of your class attribute, with different values between them;
2. Create two objects, instances of the class that you want to test, call one as base and the other as ref;
3. Make this block of code for each attribute (it doesn't matter the sequence):

base.setAttribute(ATTRIBUTE);     ref.setAttribute(DIF_ATTRIBUTE);     assert !base.equals(ref);     ref.setAttribute(ATTRIBUTE);     assert base.equals(ref);

Making things like this will insure that your test code for equals works perfect. Let's say that it is a little bit painful to make it for a big class, but of course you could automate it.