TSS at Prague was great. Great sessions, always great meeting up with people from all over the world. Sadly, I did not manage to get to too many sessions, had to work a bit on GigaSpaces upcoming 6.5 GA release, but the ones I went to were really good.

I also did a tech talk with Jason Carriera. I was talking about next generation application servers and Jason was talking about his experience working with GigaSpaces (he is working on a really cool app, I won’t spoil the surprise) and also about the OpenSpaces developer contest where he won the third place.

I also gave a presentation titles “Beyond a Data Grid” where I try to talk about things that can be done with a DataGrid beyond your typical Cache#put and Cache#get mainly through examples. Here is the presentation (mostly pictures, but still ;) ):

| View | Upload your own

ITS ABOUT TIME!

As I posted before, I am reading the wonderful Dune book again. Another quote from Dune reminded me of problems we have when trying to build a scalable application:

Kynes looked at Jessica, said: “The newcomer to Arrakis frequently underestimate the importance of water here. You are dealing, you see, with the Law of the Minimum.”

She heard the testing quality in his voice, said, “Growth is limited by the necessity which is present in the least amount. And, naturally, the least favorable condition controls the growth rate.”

“It’s rare to find members of a Great House aware of planetological problems,” Kynes said. “Water is the least favorable condition for life on Arrakis. And remember that growth itself can produce unfavorable conditions unless treated with extreme care”.

So true. When we build an application and notice some performance problems, we first need to try and nail down the “least favorable condition”. For example, if we have a messaging system talking to a database, and we notice a bottleneck in the messaging system, we first need to tackle it.

But, “growth itself can produce unfavorable conditions”. We might find that we increased the growth in our messaging system two fold, only to find that our database became the next bottleneck which allowed our system to grow in a much smaller factor.

Even so, “unfavorable conditions” can be much worse, where we find that our whole architecture can simply not scale anymore, and we have to re-architect it to meet our needs. Extreme care, Kynes said, and he is right… .

In a paper titled The end of an architectural era (It’s time for a complete rewrite), Mike Stonebraker, Ingres founder and a Postgres architect, with a group of academics said that modern use of computers renders many features of mainstream DBMS obsolete.

They have argued that DBMS designs such as Oracle and SQL Server come from an age when online transaction processing (OLTP) dominated and required techniques such as multi threading and transaction locking. They said that modern transactions - entered via web pages - do not need these expensive processing overheads and DBMS should, therefore, be re-designed without them. Persistent storage such as disks are also seen as unnecessary and could be replaced by geographically dispersed RAM storage.

Stonebraker and his group also advocate abandoning SQL because they see no need for a separate data manipulation language. Data manipulation, they said, can be performed with other tasks using languages such as Ruby. They describe a prototype DBMS called H-Store that embodies these ideas.

This paper is a very interesting read, and basically acknowledge the hard work that DataGrid providers such as GigaSpaces and Tangosol have been advocating for a long time. One thing that I do have to comment regarding the article is the fact that Mr. Stonebraker and the rest of the group fail to take this architecture to the next level of integrating such a solution into the “application tier”. I guess this is mainly due to the fact of the “remote database” concept that is inherit when working with databases.

What do I mean by that? Very simple. Once we have our data stored in memory, we can bring it “into” our application tier. This means that operations that we perform will actually be done in memory without even leaving our “vm”. Naturally, the next question that is asked then is what do you do with partitioning? Well, the idea is to have the processing of data redirected into the partition that will hold most (if not all) the relevant data that is required for its processing (the one that is not can still be accessed in a remote “clustered” manner).

Another interesting point is the replacement of SQL with better ways to query for data. For one, the simplest thing can be to define our queries based on the objects we work on. For example, create a “template” of an Order where its processed flag is set to false. Advance queries can be based on dynamic languages such as ruby and groovy, which is exactly what I have been hacking around in GigaSpaces for our upcoming version (more information can be found here).

Its great to see this movement starting to happen within the database world.

I was really happy when DZone came out. I was missing something like Digg but with more focus on technology and development from (mostly) that Java point of view. So, here I was hoping that content that many people find interesting will filter its way into my RSS reader.

Sadly, astrosurfing has found its way into DZone as well. What do I mean by Astrosurfing? I mean that content created by vendors will be pumped up by the vendor and be “regarded” as important news, even though the vendor did all the voting on the content.

The most obvious example is Nikita Ivanov blog, which its content is submitted to DZone. Lets take the following post (which I find pretty silly, but thats just me) which you can find here. If you look at the votes for the link you can find the following voters dsetrakyan, mvandoornik, skh, sbob, dkharlamov, magdenko_alex which strangely enough, always vote for GridGain, and somethings even just vote for GridGain. This can be validated by going to other posts made by Nikita and applying the same logic.

Personally, I view this type of voting as spam. Naturally, other people (I wonder who ;) ) will disagree, but for me, the fact that a company finds its content interesting is irrelevant to the rest of the community.

I guess that the main question is how to tackle this. Rick and Matt are doing a wonderful job, and it is not a simple problem to solve. One option, which they started recently, is creating specific zones such as Groovy Zone with expert people to moderate it.

Another simple solution can be ignoring people who seem to be voting for the same person all the time, as well as reducing the voting power of new users. This is simple mechanism, though obviously can be circumvented, that should reduce this spam posts.

I guess the main reason digg works well and dzone falls a bit short is the fact that there are so many people voting in digg. When you only display content that was voted a thousand times, then the fact that a company such as GridGain with its 5 developers won’t be able to make such an impact. In this sense, the responsibility falls on our shoulders to vote (which I personally have not been doing as much as I should have).

As for low voting sites it is a bit hard to spam out content (without moderation). For example, lets say we suggest voting on people and that will control the actual ranking of a certain story. You still get into the problem of who votes for this people. Other types of solution gets into this “chicken and the egg” problem.

What do you say? Do you have a better solution for this problem? Does this content bothers you or do you even consider it as not spam?

Rick, Matt and the rest of the DZone (and other) people. Thanks you for all your effort, and I hope we will manage to find a solution for this…

Sun just bought MySQL, and Oracle just bought BEA. Interesting times …, what do you say?

Well, just found out about a built in integration between IntelliJ IDEA and Jira which is really cool. Head over to your project Version Control settings, go to Issue Navigation, and over there, add your Jira instance url. Cool!

Just came across this video which cranked me silly:

And usually, it got me started thinking about software development and especially Java next version. For example, press play and sing the following lyrics:

Java 7 coming out
exciting times, maybe not

Still working on version 5
OSX sucks

Thought I use the perfect language
JSR make me anguish

learned about closures
to find out its a worthless pile of crap

suffered through the ruby craze
to find out its not a phase

OSGi, Java modules,
would you like to place a bet?

old JSRs are here again,
JCACHE, XML

time to write a Java book,
it will be 1500 pages long!

here comes another version,

its a shameless copy
of .NET and ruby

first you need a closure,
then a second and a third

take at least three shots
at getting generics right

find yourself a task to do
fork it out, join it back

just a pretty way to say
map reduce all the way

need a cool feature list
must be simple, backward compatible

something cool like
invokedynamic, BigDecimal, multicach, and rethrown

write yourself a simple switch
code it up just with strings

add some setters to your bean
chain them up, sexy beast

here comes another version

SUN is rocking,
so don’t come a knocking

fight fight fight it out
fight it if its big or small

Anybody care to continue? :)

Here is a great example why IntelliJ will always win. With the latest milestone, you can now find usages (references in Eclipse lingo) and see them as a context popup. Here is how it looks like:

As someone who uses this feature all the time, this is an amazing time saver (instead of showing it in a different view). IntelliJ is simply swamped with such small features.

Just read an excellent article over at devx called Multi-core Mythbusters. The article is very good at explaining in layman’s terms the need for scalability. The article title is a bit misleading as it even talks about scaling out an application across machines (or for that purpose, JVM instances). What really hit the mark for me is this:

Although it is true that Java app servers provide a degree of concurrency, many Java developers are under the mistaken impression that the app server will simply take care of all of their scalability needs.

This is probably one of the most cherished viewpoints of the J2EE server space. As such, it is one of the most tenacious in the face of arguments to the contrary. Fortunately, it doesn’t take a great deal of logical reasoning to see its inherent flaws. The belief begins with the basic assumption that when a particular J2EE application does not scale, it is due to the CPU not running fast enough. For most of today’s applications, however, the CPU is not being kept busy. A large part of the application server execution time is spent transmitting data back and forth across components, taking out locks, or waiting for locks to be released. Spending some quality time with a profiler can show you just how much time your application spends on these tasks, which cannot benefit from a faster CPU.

This is a great explanation of why application server mostly simply do not cut it. I have been talking for some time now about the need for some sort of a “Next Generation App Server”. The next generation part in my case revolves around how to write scalable application in a simplified manner.

One of the main problems with current application servers is the fact that there are many different moving parts such as JMS, EJB, and JPA without tight integration between them. Another main problem is the fact that JEE missed an important aspect for writing scalable application, which is the data grid.

Now, lets assume we live in a perfect world. We would have all this moving/missing parts handled by the same library. We would have the ability to store our domain model within a data grid, be able to register and receive events due to changes of the domain model within the data grid (allowing us to have an EDA / ESB like support), and be able to perform parallel operations (ala Map Reduce) simply using our domain model.

In such a scenario, our clients will either work in an embedded mode with our data/event grid, or work with it remotely and be able to perform all the operations on a single system image which is our grid (such as write and take objects from the gird, register for events, and so on). They could even create a running window over a subset of the data. This clients will probably be either RIA or fat clients.

To wrap the story, it would be great if we can have the same, simple deployment model that application servers allow us, with the addition of smart relocation and service level definitions for different bundles.

Though naturally this is not a perfect world, GigaSpaces is certainly heading in the right direction (in my neutral opinion ;) ). The latest release, with OpenSpaces (which your not so humble blogger was responsible for) and GigaSpaces core functionality, we are now very close at realizing such an architecture.

There is no doubt, in my mind, that this type of architecture will be part of any future applications, as explained so eloquently in the devx article. I bet this is how Hibernate/TopLink/Kodo felt before JPA. A storm is coming…