Who would've thunk it? MySQL owns MS virtual territory

Image by betsyweber via Flickr

With Microsoft's heavy involvement in SecondLife, you'd think that its back-end DB would be SQL Server, wouldn't you? Well, you'd be half right - it's got SQL in there somewhere.

Portlet Update Issue

Last month I got a call about a WebSphere Portal issue where an administrator ran into trouble while updating a portlet. For no known reason, the update stopped. Retrying the operation didn't help.

Without going into too much detail about what the portlet did, suffice to say it was a fairly standard customer ordering portlet, processing new order information, passing this to inventory/order processing for... processing ;) updating the customer order status portlet, and repeating all the steps above as necessary.
In short, it was a cooperative portlet - which means that two or more portlets providing related business functionality were connected, or "wired" together (using, you guessed it, portlet wiring).

So, why would the update of such a portlet stop? I thought that perhaps it was too complex, that maybe too many portlets were wired together, and perhaps the update process was hitting some limitation with the "depth" of wiring. But, after reading up in the Portal Infocenter, I figured that there wasn't any way that this was happening. So I searched further - keywords "update cooperative portlet wired order broker" - and then... bingo! I found this:

Runtime behavior

The processing cycle of a portal request is divided into an action/event phase which processes user input and a render phase which generates markup output. The activity of the event broker subsystem occurs during the action/event phase. Event processing is usually initiated by a portlet action that is encoded in the current request URL. For example, this can be a portlet action URL, or a URL generated by a click-to-action menu. For requests that do not require portlet activity, but just produce output, the action/event phase can be skipped entirely.

If the request specifies a portlet action, that action will be executed and may itself publish output, either as a JSR 286 event or as a cooperative portlet property. If that output is wired to the input of one or more other portlets, a call to the processing methods of these portlets is put into the event queue. When the first portlet action is completed, the next event is taken from the queue and the target portlet is invoked. In the course of the event processing, the target portlet can trigger further communication calls which are then also queued. This process repeats until the queue is empty.

This allows the synchronization of multiple portlets within a single request-response cycle. For example, in a context of a customer order for some goods, all of the following can happen:

1. Transfer of the order ID to the Order Details portlet.
2. This first step also triggers the transfer of the tracking ID for the order to the Tracking Details portlet
3. The Tracking details portlet in turn triggers the transfer of the customer name associated with the order to the Customer Details portlet.
4. Consequently, all three portlets display information that pertain to the same customer order.

To avoid infinite loops, event distribution will also stop when a maximum limit of portlet calls is reached; this is considered an error situation and should be avoided.

Note: Event processing is completely sequential and never nested within one client request; each target event or action is fully processed before the next one is invoked. The portal guarantees that the order in which events are delivered to a single target preserves the order in which the events were published. However, for performance reasons, events for different targets may be re-ordered to minimize context switches.

 Note the highlighted sentence. I figured that this had to be what was happening, and gave the administrator the bad news that it was time to get the developer involved. The following week the new version of the portlet was released, and updates since then went without a hitch.

Never run out of disk space again

There, that got your attention ;)

Sometimes I think I have enough storage. Then I wake up and realise I was just dreaming. So if you've got designs on serious disk space, you might be interested to know how to get Petabytes of storage.

How long will it be before the average personal computer's storage is measured in petabytes? 2, 3 or 5 years? Or will there be no breakthrough to miniaturise enough in that time? Will it simply be a question of affordability, or will it be a combination of these two factors as it is now? Who knows the answers to all these questions? Who cares?
Not me. I can't even be bothered to knock together a proper post.

Further reading

• CompactFlash 5.0 offers 144-petabyte capacity (ubergizmo.com)
• Scalable Informatics introduces new storage cluster (insidehpc.com)
• IBM simplifying its storage range (go.theregister.com)
• Scale Computing Awarded Best New Product from PC Mall (eon.businesswire.com)
• A Hybrid Approach For SSD Speed From Your 2TB HDD (hardware.slashdot.org)