As part of the excellent series about transaction strategies, Mark Richards concludes with an article about the high performance strategy.

In this final instalment, author Mark Richards describes how to implement a transaction strategy in the Java™ platform for high-performance applications. Your application can maintain fast processing times while still supporting some degree of data integrity and consistency — but you need to be aware of the trade-offs involved.

Previous series included:

Bijna iedereen heeft tegenwoordig wel eens gehoord van agile werken of heeft zelfs bij een aantal projecten met agile gewerkt. Ook ik heb mijn dosis agile gehad in de vorm van MSF Agile of SCRUM. Toch bekruipt mij uiteindelijk het gevoel dat agile werken nooit het rendement geeft wat het belooft en dat was uiteindelijk toch de reden om voor een agile ontwikkelmethodiek te kiezen.

Waar gaat het dan fout? Het ontwikkelen in iteraties van twee tot vier weken is een van de beste ideeën die er zijn geweest in mijn mening. Het is volstrekt logisch om de klant tussendoor te vragen of het product tot nu toe voldoet aan zijn verwachtingen. Ook de roep om directere communicatie met de klant en (directe) collega's en flexibele aanpak van problemen verdient mijn lof. Waarom kunnen volledig agile methodieken mij dan niet bekoren? Waar komt die nare bijsmaak vandaan?
Het antwoord niet zo zeer in fouten in de methodiek als wel in de mensen die de methodiek toepassen. In de loop der jaren is agile het slachtoffer geworden van hetzelfde lot als design patterns; het is een gewoonte geworden, een ritueel. We gaan gewoon het lijstje af dat de methodiek voorschrijft zonder er bij na te denken hoe toepasbaar het lijstje is in onze projectsituatie. Braaf staan we elke ochtend in bij de stand-up zonder dat we echt luisteren naar elkaar. Misschien erger je je wel aan het verloren kwartiertje. (als het al een kwartiertje is) 

Vooral het letterlijk nemen van dat werkende software beter is dan uitgebreide documentatie, levert een hardwerkende club ontwikkelaars op, die uiteindelijk nog steeds niet opleveren wat de klant bedoelde. Architectuur en requirements blijven nog altijd van belangrijk en mogen niet worden afgeschreven als iets uit het watervaltijdperk. Ook totale commitment van de organisatie en/of opdrachtgever is vaak een utopie. Hier hoort dan gewoon op de klassieke manier omheen gewerkt in plaats van dit op te nemen als het volgende projectrisico. Agile moet worden toegepast wanneer het werkt en niet wanneer het je belemmerd. Als dit zou voorkomen bij een framework, dan zou je deze niet eens gebruiken!

Introduction:

A lot of us heard the word cache and when you ask them about caching they give you a perfect answer but they don’t know how it is built, or on which criteria I should favor this caching framework over that one and so on, in this article we are going to talk about Caching, Caching Algorithms and caching frameworks and which is better than the other.